From shaojin.wensj at alibaba-inc.com Sun Oct 1 00:49:08 2023 From: shaojin.wensj at alibaba-inc.com (=?UTF-8?B?5rip57uN6ZSmKOmrmOmTgSk=?=) Date: Sun, 01 Oct 2023 08:49:08 +0800 Subject: =?UTF-8?B?QW4gZXJyb3Igd2lsbCBiZSByZXBvcnRlZCB3aGVuIGNvbXBpbGluZyB0aGUgbWFzdGVyIG9u?= =?UTF-8?B?IE9yYW5nZVA1IFBsdXM=?= Message-ID: <78fec0b7-7ee1-4f66-99c3-2fb746ea8e6f.shaojin.wensj@alibaba-inc.com> An error will be reported when compiling the master on OrangeP5 Plus (http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html ), but the compilation of the 21u version is passed. The error message is as follows: ``` Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar Creating support/classlist.jar /usr/bin/bash: line 15: 854142 Aborted /root/git/jdk/build/linux-aarch64-server-release/support/interim-image/bin/java -XX:DumpLoadedClassList=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.raw.2 -XX:SharedClassListFile=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.interim -XX:SharedArchiveFile=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.jsa -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -Duser.language=en -Duser.country=US --module-path /root/git/jdk/build/linux-aarch64-server-release/support/classlist.jar -cp /root/git/jdk/build/linux-aarch64-server-release/support/classlist.jar build.tools.classlist.HelloClasslist 2> /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/stderr > /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/default_jli_trace.txt ERROR: Failed to generate link optimization data. This is likely a problem with the newly built JVM/JDK. # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (macroAssembler_aarch64.cpp:4654), pid=854142, tid=854143 # guarantee((shifted_base & 0xffff0000ffffffff) == 0) failed: compressed class base bad alignment # # JRE version: (22.0) (build ) # Java VM: OpenJDK 64-Bit Server VM (22-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0xae20d0] MacroAssembler::decode_klass_not_null(Register, Register)+0x250 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /root/git/jdk/make/hs_err_pid854142.log # # gmake[3]: *** [GenerateLinkOptData.gmk:71: /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist] Error 134 gmake[2]: *** [make/Main.gmk:649: generate-link-opt-data] Error 2 gmake[2]: *** Waiting for unfinished jobs.... ERROR: Build failed for target 'images' in configuration 'linux-aarch64-server-release' (exit code 2) Stopping javac server No indication of failed target found. HELP: Try searching the build log for '] Error'. HELP: Run 'make doctor' to diagnose build problems. make[1]: *** [/root/git/jdk/make/Init.gmk:323: main] Error 2 make: *** [/root/git/jdk/make/Init.gmk:189: images] Error 2 ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid854142.log Type: application/octet-stream Size: 48743 bytes Desc: not available URL: From dl at openjdk.org Sun Oct 1 13:36:56 2023 From: dl at openjdk.org (Doug Lea) Date: Sun, 1 Oct 2023 13:36:56 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v44] In-Reply-To: References: Message-ID: > Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues. > > This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities. Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 92 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8288899 - refactor termination - Undo stray edit - Streamline push; add redundant interrupts - Merge branch 'openjdk:master' into JDK-8288899 - Possibly re-interrupt when stopping - more conservative resize checks - Merge branch 'openjdk:master' into JDK-8288899 - Ensure publishabliity on resize - Fix and improve windowing - ... and 82 more: https://git.openjdk.org/jdk/compare/d6fda33e...71ab0a2f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14301/files - new: https://git.openjdk.org/jdk/pull/14301/files/9b714224..71ab0a2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=43 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=42-43 Stats: 1542 lines in 37 files changed: 725 ins; 344 del; 473 mod Patch: https://git.openjdk.org/jdk/pull/14301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301 PR: https://git.openjdk.org/jdk/pull/14301 From jlu at openjdk.org Mon Oct 2 05:46:58 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 2 Oct 2023 05:46:58 GMT Subject: Integrated: 5066247: Refine the spec of equals() and hashCode() for j.text.Format classes In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 21:24:18 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315720) which refines the spec of `equals()` and `hashCode()` in `java.text.Format` related classes. > > The current spec for most of these methods is either "_Overrides _" or are incomplete/wrong (i.e. see `ChoiceFormat`). > > This fix adjusts the spec to provide a consistent definition for the overridden methods and specify what is being compared/used to generate a hash code value. > > For implementations that use at most a few fields, the values are stated, otherwise a more general term is used as a substitution (i.e. see `DecimalFormat`). This pull request has now been integrated. Changeset: 8fcf70e9 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/8fcf70e931cd2e69e644c459d16d1410ce7ff3ae Stats: 142 lines in 9 files changed: 117 ins; 1 del; 24 mod 5066247: Refine the spec of equals() and hashCode() for j.text.Format classes Reviewed-by: naoto, darcy ------------- PR: https://git.openjdk.org/jdk/pull/15459 From asotona at openjdk.org Mon Oct 2 08:34:19 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 2 Oct 2023 08:34:19 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v3] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed javadoc typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15706/files - new: https://git.openjdk.org/jdk/pull/15706/files/77631a78..df02df8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15706.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706 PR: https://git.openjdk.org/jdk/pull/15706 From asotona at openjdk.org Mon Oct 2 08:34:24 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 2 Oct 2023 08:34:24 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v2] In-Reply-To: <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com> Message-ID: On Fri, 29 Sep 2023 23:00:44 GMT, Vicente Romero wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> PreviewFeature annotated with JEP 457 > > make/jdk/src/classes/build/tools/module/GenModuleInfoSource.java line 476: > >> 474: throw parser.newError("is malformed"); >> 475: } >> 476: } else if (token.equals("import")) { > > why was this change necessary? It allows to use imports in module infos, so annotations do not need to use FQN. > src/java.base/share/classes/java/lang/classfile/AnnotationElement.java line 34: > >> 32: import jdk.internal.javac.PreviewFeature; >> 33: >> 34: /** > > shouldn't we have the preview header applied to all these compilation units?: > > > {@preview Associated with pattern matching for instanceof, a preview feature of the Java language. I'm not aware of preview javadoc tag, could you point me to an example? > src/java.base/share/classes/java/lang/classfile/Attributes.java line 174: > >> 172: public static final String NAME_RUNTIME_INVISIBLE_ANNOTATIONS = "RuntimeInvisibleAnnotations"; >> 173: >> 174: /** RuntimeInvisibleTypeAnnotations */ > > this comment should probably be: RuntimeInvisibleParameterAnnotations Fixed, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342320443 PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342347591 PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342319521 From claes.redestad at oracle.com Mon Oct 2 11:22:55 2023 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 Oct 2023 11:22:55 +0000 Subject: Adding appendHex method to StringBuilder In-Reply-To: References: Message-ID: I think this goes against the grain: StringBuilder is a simple builder for non-localized unformatted output. For formatted output there?s Formatter, String.format and, with JEP 430[1], FMT.??? to help output string data in more advanced, formatted and localized ways. The latter has traditionally lacked a bit in raw throughput, and String templates is a deep-cut approach to try and improve both the programming model and the performance characteristics. Let?s compare a few existing APIs (JDK 22 ea, ?enable-preview enabled for the FMT.??? micro: @Benchmark public String toStringAppendHex8() { StringBuilder result = new StringBuilder(); result.append(Integer.toHexString(2048)); result.append(Integer.toHexString(31337)); result.append(Integer.toHexString(0xbeefcace)); result.append(Integer.toHexString(9000)); result.append(Integer.toHexString(4711)); result.append(Integer.toHexString(1337)); result.append(Integer.toHexString(2100)); result.append(Integer.toHexString(2600)); return result.toString(); } @Benchmark public String toStringFMTHex8() { int h1 = 2048, h2 = 31337, h3 = 0xbeefcace, h4 = 9000, h5 = 4711, h6 = 1337, h7 = 2100, h8 = 2600; return FMT."%x\{h1}%x\{h2}%x\{h3}%x\{h4}%x\{h5}%x\{h6}%x\{h7}%x\{h8}"; } @Benchmark public String toStringFormatHex8() { StringBuilder result = new StringBuilder(); Formatter f = new Formatter(result); f.format("%x", 2048); f.format("%x", 31337); f.format("%x", 0xbeefcace); f.format("%x", 9000); f.format("%x", 4711); f.format("%x", 1337); f.format("%x", 2100); f.format("%x", 2600); return result.toString(); } @Benchmark public String toStringFormatCombinedHex8() { return String.format("%x%x%x%x%x%x%x%x", 2048, 31337, 0xbeefcace, 9000, 4711, 1337, 2100, 2600); } Benchmark Mode Cnt Score Error Units StringBuilders.toStringAppendHex8 avgt 15 19,521 ? 0,608 ns/op StringBuilders.toStringFMTHex8 avgt 15 10,958 ? 0,838 ns/op StringBuilders.toStringFormatHex8 avgt 15 378,327 ? 9,302 ns/op StringBuilders.toStringFormatCombinedHex8 avgt 15 235,609 ? 6,315 ns/op As we can see FMT.?%x?? is already a great deal faster here, while String.format and Formatter leave something to be desired. One thing missing with the FMT approach is a natural way to format into pre-existing StringBuilder/Appendable (like the toStringFormatHex8 benchmark models). I think adding that would be a way more interesting development than to add more formatting methods to StringBuilder. /Claes [1] https://openjdk.org/jeps/430 30 sep. 2023 kl. 14:06 skrev ???(??) : There are many combinations of `append(Integer.toHexString(i))` and `append(Long.toHexString(i))` in the JDK code. I request to add method `appendHex(int)` and `appendHex(int)` to StringBuilder and StringBuffer. This can reduce duplicate code within the JDK and will also be useful to users. I submitted a PR ( https://github.com/openjdk/jdk/pull/15998 ), including the code and tests for the new method. I also replaced the code that uses the append + toHexString combination inside the JDK with appendHex. Please review and don't hesitate to critique my approach and patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Mon Oct 2 12:18:57 2023 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 2 Oct 2023 12:18:57 +0000 Subject: Adding appendHex method to StringBuilder In-Reply-To: References: Message-ID: <20231002081855.176913415@eggemoggin.niobe.net> 2023/10/2 7:22:55 -0400, claes.redestad at oracle.com: > I think this goes against the grain: StringBuilder is a simple builder > for non-localized unformatted output. For formatted output there?s > Formatter, String.format and, with JEP 430[1], FMT."..." to help output > string data in more advanced, formatted and localized ways. Agreed. If we were to introduce a `fooBar(x)` method for every common `foo(bar(x))` expression in the JDK code base then our APIs would fast become inscrutable. - Mark From shaojin.wensj at alibaba-inc.com Mon Oct 2 12:46:55 2023 From: shaojin.wensj at alibaba-inc.com (=?UTF-8?B?5rip57uN6ZSmKOmrmOmTgSk=?=) Date: Mon, 02 Oct 2023 20:46:55 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaQWRkaW5nIGFwcGVuZEhleCBtZXRob2QgdG8gU3RyaW5nQnVpbGRlcg==?= In-Reply-To: <20231002081855.176913415@eggemoggin.niobe.net> References: , <20231002081855.176913415@eggemoggin.niobe.net> Message-ID: Using String Template FMT has better performance and better code readability. But String Template does not yet support for/while/if/switch. Is there any plan to enhance String Template to support for/while/if/switch? The following scenarios cannot be implemented using String.format or String Template. I think whether to build in support for foo(bar(x)) depends on whether it is a common enough method. ```java package java.net; class Inet6Address extends InetAddress { static String numericToTextFormat(byte[] src) { StringBuilder sb = new StringBuilder(39); for (int i = 0; i < (INADDRSZ / INT16SZ); i++) { sb.append(Integer.toHexString(((src[i<<1]<<8) & 0xff00) | (src[(i<<1)+1] & 0xff))); if (i < (INADDRSZ / INT16SZ) -1 ) { sb.append(":"); } } return sb.toString(); } } class SocketPermission { private boolean authorizedIPv6(String cname, byte[] addr) { String authHost = ""; InetAddress auth; try { StringBuilder sb = new StringBuilder(39); for (int i = 15; i >= 0; i--) { sb.append(Integer.toHexString(((addr[i]) & 0x0f))); sb.append('.'); sb.append(Integer.toHexString(((addr[i] >> 4) & 0x0f))); sb.append('.'); } ... } } ``` ```java package sun.security.krb5.internal.crypto.dk; class DkCrypto { static String bytesToString(byte[] digest) { // Get character representation of digest StringBuilder digestString = new StringBuilder(); for (int i = 0; i < digest.length; i++) { if ((digest[i] & 0x000000ff) < 0x10) { digestString.append('0').append(Integer.toHexString(digest[i] & 0x000000ff)); } else { digestString.append( Integer.toHexString(digest[i] & 0x000000ff)); } } return digestString.toString(); } } ``` - wenshao ------------------------------------------------------------------ ????Mark Reinhold ?????2023?10?2?(???) 20:19 ????Claes Redestad ???????(??) ; core-libs-dev at openjdk.org ????Re: Adding appendHex method to StringBuilder 2023/10/2 7:22:55 -0400, claes.redestad at oracle.com: > I think this goes against the grain: StringBuilder is a simple builder > for non-localized unformatted output. For formatted output there?s > Formatter, String.format and, with JEP 430[1], FMT."..." to help output > string data in more advanced, formatted and localized ways. Agreed. If we were to introduce a `fooBar(x)` method for every common `foo(bar(x))` expression in the JDK code base then our APIs would fast become inscrutable. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Mon Oct 2 13:33:36 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 2 Oct 2023 13:33:36 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v3] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona wrote: >> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. >> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. >> It repackages all uses across JDK and tests and adds lots of missing Javadoc. >> >> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) >> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). >> >> Online javadoc is available at:? >> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html >> >> In addition to the primary transition to preview, this pull request also includes: >> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). >> - A new preview feature, `CLASSFILE_API`, has been added. >> - Buildsystem tool required a little patch to support annotated modules. >> - All JDK modules using the Classfile API are newly participating in the preview. >> - All tests that use the Classfile API now have preview enabled. >> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. >> >> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. >> >> Please review this pull request to help the Classfile API turn into a preview. >> >> Any comments are welcome. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed javadoc typo src/java.base/share/classes/java/lang/classfile/ClassTransform.java line 164: > 162: > 163: /** > 164: * @implSpec Should these overridden method have `@inheritDoc` ? If not, their javadoc won't show much, I believe. (same might be true for other methods) src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 596: > 594: * @param type the object type > 595: * @return this builder > 596: * @throws IllegalArgumentException if {@code type} represents a primitive type What about arrays? (ClassDesc has an `isArray` predicate too). This probably applies to other methods too. src/java.base/share/classes/java/lang/classfile/CodeTransform.java line 101: > 99: > 100: /** > 101: * @implSpec The default implementation returns a resolved transform; `... returns a resolved transform that is bound to the given code builder` or `... returns a resolved transform bound to the given code builder` src/java.base/share/classes/java/lang/classfile/FieldTransform.java line 116: > 114: > 115: /** > 116: * @implSpec The default implementation returns a resolved transform with all Perhaps lose the `all its parts` - not sure that makes the comment any clearer? src/java.base/share/classes/java/lang/classfile/MethodSignature.java line 59: > 57: > 58: /** > 59: * {@return method signature for a raw (no generic information) method descriptor} Isn't this missing an article - e.g. `return the method signature` or `return a method signature` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342685585 PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342691511 PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342693515 PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342694834 PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342696367 From mcimadamore at openjdk.org Mon Oct 2 13:33:36 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 2 Oct 2023 13:33:36 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v3] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com> On Mon, 2 Oct 2023 13:19:48 GMT, Maurizio Cimadamore wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed javadoc typo > > src/java.base/share/classes/java/lang/classfile/ClassTransform.java line 164: > >> 162: >> 163: /** >> 164: * @implSpec > > Should these overridden method have `@inheritDoc` ? If not, their javadoc won't show much, I believe. (same might be true for other methods) (To be precise - the javadoc says "Description copied from interface: ClassFileTransform") - just make sure that's what you want. > src/java.base/share/classes/java/lang/classfile/FieldTransform.java line 116: > >> 114: >> 115: /** >> 116: * @implSpec The default implementation returns a resolved transform with all > > Perhaps lose the `all its parts` - not sure that makes the comment any clearer? I've noted the same pattern in other similar methods ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342689301 PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342697392 From mcimadamore at openjdk.org Mon Oct 2 13:38:23 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 2 Oct 2023 13:38:23 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v3] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona wrote: >> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. >> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. >> It repackages all uses across JDK and tests and adds lots of missing Javadoc. >> >> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) >> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). >> >> Online javadoc is available at:? >> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html >> >> In addition to the primary transition to preview, this pull request also includes: >> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). >> - A new preview feature, `CLASSFILE_API`, has been added. >> - Buildsystem tool required a little patch to support annotated modules. >> - All JDK modules using the Classfile API are newly participating in the preview. >> - All tests that use the Classfile API now have preview enabled. >> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. >> >> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. >> >> Please review this pull request to help the Classfile API turn into a preview. >> >> Any comments are welcome. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed javadoc typo src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 310: > 308: * @param implClasses the implementation classes > 309: * @return this builder > 310: * @throws IllegalArgumentException if {@code service} or any of the {@code implClasses} represents a primitive type Javadoc tip (not that you should use that here) - if the thrown clause becomes too complex, you can also split it into multiple `throws IllegalArgumentException`. Sometimes that can improve readability. src/java.base/share/classes/java/lang/classfile/attribute/ModuleResolutionAttribute.java line 75: > 73: * The value of the resolution_flags item is a mask of flags used to denote > 74: * properties of module resolution. The flags are as follows: > 75: * 
 {@code

Why not a snippet?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342702250
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342703022

From mcimadamore at openjdk.org  Mon Oct  2 13:43:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 13:43:24 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

src/java.base/share/classes/java/lang/classfile/attribute/package-info.java line 27:

> 25: 
> 26: /**
> 27:  * 
Provides interfaces describing classfile attributes for the {@link java.lang.classfile} library.


Not 100% sure about the use of `h2` (here and elsewhere).

src/java.base/share/classes/java/lang/classfile/components/ClassPrinter.java line 51:

> 49:  * Level of details to print or to export is driven by {@link Verbosity} option.
> 50:  * 

> 51:  * Printing is for debugging purposes only. Printed text schema and tree content and structure

Suggestion:

 * Printing is for debugging purposes only. Printed text schema, tree content and structure

src/java.base/share/classes/java/lang/classfile/components/CodeRelabeler.java line 71:

> 69:      * Creates a new instance of CodeRelabeler using provided {@link java.util.function.BiFunction}
> 70:      * to re-label the code.
> 71:      * @param mapFunction function remapping labels

I found this a bit hard to read. Maybe expand to "function for remapping labels in the source code model", or something similar

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342707029
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342707621
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342709706

From claes.redestad at oracle.com  Mon Oct  2 13:45:30 2023
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 2 Oct 2023 13:45:30 +0000
Subject: Adding appendHex method to StringBuilder
In-Reply-To: 
References: 
 
 <20231002081855.176913415@eggemoggin.niobe.net>
 
Message-ID: <1CC3C02C-EFAC-4412-BB01-FEB0D379039E@oracle.com>

It?s possible to build up and combine unprocessed RAW template snippets, then combine and process them together:


static int[] val = new int[] { 2048, 31337, 0xbeefcace, 9000, 4711, 1337, 2100, 2600 };
@Benchmark
public String toStringFMTCombineHex8() {
    var templates = new ArrayList();
    for (int i = 0; i < 8; i++) {
        int h = val[i];
        templates.add(RAW."%x\{h}");
    }
    return StringTemplate.combine(templates).process(FMT);
}

Performance is? not great, but I think we can and should work on that:

Benchmark                                  Mode  Cnt     Score     Error  Units
StringBuilders.toStringFMTCombineHex8      avgt   15  2421,151 ? 646,501  ns/op

/Claes

2 okt. 2023 kl. 14:46 skrev ???(??) :

Using String Template FMT has better performance and better code readability. But String Template does not yet support for/while/if/switch. Is there any plan to enhance String Template to support for/while/if/switch? The following scenarios cannot be implemented using String.format or String Template. I think whether to build in support for foo(bar(x)) depends on whether it is a common enough method.

```java
package java.net;
class Inet6Address extends InetAddress {
    static String numericToTextFormat(byte[] src) {
        StringBuilder sb = new StringBuilder(39);
        for (int i = 0; i < (INADDRSZ / INT16SZ); i++) {
            sb.append(Integer.toHexString(((src[i<<1]<<8) & 0xff00)
                                          | (src[(i<<1)+1] & 0xff)));
            if (i < (INADDRSZ / INT16SZ) -1 ) {
              sb.append(":");
            }
        }
        return sb.toString();
    }
}
class SocketPermission {
  private boolean authorizedIPv6(String cname, byte[] addr) {
        String authHost = "";
        InetAddress auth;
        try {
            StringBuilder sb = new StringBuilder(39);
            for (int i = 15; i >= 0; i--) {
                sb.append(Integer.toHexString(((addr[i]) & 0x0f)));
                sb.append('.');
                sb.append(Integer.toHexString(((addr[i] >> 4) & 0x0f)));
                sb.append('.');
            }
        ...
  }
}
```
```java
package sun.security.krb5.internal.crypto.dk;
class DkCrypto {
    static String bytesToString(byte[] digest) {
        // Get character representation of digest
        StringBuilder digestString = new StringBuilder();
        for (int i = 0; i < digest.length; i++) {
            if ((digest[i] & 0x000000ff) < 0x10) {
                digestString.append('0').append(Integer.toHexString(digest[i] & 0x000000ff));
            } else {
                digestString.append(
                    Integer.toHexString(digest[i] & 0x000000ff));
            }
        }
        return digestString.toString();
    }
}
```

- wenshao

------------------------------------------------------------------
????Mark Reinhold 
?????2023?10?2?(???) 20:19
????Claes Redestad 
???????(??) ; core-libs-dev at openjdk.org 
????Re: Adding appendHex method to StringBuilder

2023/10/2 7:22:55 -0400, claes.redestad at oracle.com:
> I think this goes against the grain: StringBuilder is a simple builder
> for non-localized unformatted output. For formatted output there?s
> Formatter, String.format and, with JEP 430[1], FMT."..." to help output
> string data in more advanced, formatted and localized ways.

Agreed.

If we were to introduce a `fooBar(x)` method for every common
`foo(bar(x))` expression in the JDK code base then our APIs
would fast become inscrutable.

- Mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From shaojin.wensj at alibaba-inc.com  Mon Oct  2 14:01:10 2023
From: shaojin.wensj at alibaba-inc.com (=?UTF-8?B?5rip57uN6ZSmKOmrmOmTgSk=?=)
Date: Mon, 02 Oct 2023 22:01:10 +0800
Subject: =?UTF-8?B?5Zue5aSN77yaQWRkaW5nIGFwcGVuZEhleCBtZXRob2QgdG8gU3RyaW5nQnVpbGRlcg==?=
In-Reply-To: 
References: 
 ,
 <20231002081855.176913415@eggemoggin.niobe.net>,
 
Message-ID: <0a97f39e-953d-4530-add3-29560d29303d.shaojin.wensj@alibaba-inc.com>

StringTemplate is great and I wish I can submit PR to improve it. But I still think StringBuilder.appendHex is a basic API, not a formatted API. Just like Integer.toHexString and Long.toHexString, they are very commonly used and should be built-in.
------------------------------------------------------------------
???????(??) 
?????2023?10?2?(???) 20:46
????Mark Reinhold ; Claes Redestad 
????core-libs-dev at openjdk.org 
???????Adding appendHex method to StringBuilder
Using String Template FMT has better performance and better code readability. But String Template does not yet support for/while/if/switch. Is there any plan to enhance String Template to support for/while/if/switch? The following scenarios cannot be implemented using String.format or String Template. I think whether to build in support for foo(bar(x)) depends on whether it is a common enough method.
```java
package java.net;
class Inet6Address extends InetAddress {
 static String numericToTextFormat(byte[] src) {
 StringBuilder sb = new StringBuilder(39);
 for (int i = 0; i < (INADDRSZ / INT16SZ); i++) {
 sb.append(Integer.toHexString(((src[i<<1]<<8) & 0xff00)
 | (src[(i<<1)+1] & 0xff)));
 if (i < (INADDRSZ / INT16SZ) -1 ) {
 sb.append(":");
 }
 }
 return sb.toString();
 }
}
class SocketPermission {
 private boolean authorizedIPv6(String cname, byte[] addr) {
 String authHost = "";
 InetAddress auth;
 try {
 StringBuilder sb = new StringBuilder(39);
 for (int i = 15; i >= 0; i--) {
 sb.append(Integer.toHexString(((addr[i]) & 0x0f)));
 sb.append('.');
 sb.append(Integer.toHexString(((addr[i] >> 4) & 0x0f)));
 sb.append('.');
 }
 ...
 }
}
```
```java
package sun.security.krb5.internal.crypto.dk;
class DkCrypto {
 static String bytesToString(byte[] digest) {
 // Get character representation of digest
 StringBuilder digestString = new StringBuilder();
 for (int i = 0; i < digest.length; i++) {
 if ((digest[i] & 0x000000ff) < 0x10) {
 digestString.append('0').append(Integer.toHexString(digest[i] & 0x000000ff));
 } else {
 digestString.append(
 Integer.toHexString(digest[i] & 0x000000ff));
 }
 }
 return digestString.toString();
 }
}
```
- wenshao
------------------------------------------------------------------
????Mark Reinhold 
?????2023?10?2?(???) 20:19
????Claes Redestad 
???????(??) ; core-libs-dev at openjdk.org 
????Re: Adding appendHex method to StringBuilder
2023/10/2 7:22:55 -0400, claes.redestad at oracle.com:
> I think this goes against the grain: StringBuilder is a simple builder
> for non-localized unformatted output. For formatted output there?s
> Formatter, String.format and, with JEP 430[1], FMT."..." to help output
> string data in more advanced, formatted and localized ways.
Agreed.
If we were to introduce a `fooBar(x)` method for every common
`foo(bar(x))` expression in the JDK code base then our APIs
would fast become inscrutable.
- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mcimadamore at openjdk.org  Mon Oct  2 14:01:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:01:36 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java line 158:

> 156:      */
> 157:     default ClassEntry classEntry(ClassDesc classDesc) {
> 158:         if (requireNonNull(classDesc).isPrimitive()) {

It is not clear to me as to whether all the methods in the API deal with null correctly. What we did for FFM, assuming that the classfile API is also null-hostile by default, was to add a single test which would try to call all API methods and looking for NPEs:

https://github.com/openjdk/jdk/blob/2637e8ddc4ffe102418139f501fc0be8e9c5317b/test/jdk/java/foreign/TestNulls.java#L80

This test has saved us many times when adding/changing API methods.

src/java.base/share/classes/java/lang/classfile/instruction/CharacterRange.java line 77:

> 75:      * A flags word, indicating the kind of range.  Multiple flag bits
> 76:      * may be set.  Valid flags include
> 77:      * {@link java.lang.classfile.ClassFile#CRT_STATEMENT},

Maybe it would be better to organize the links in a bullet list?

src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java line 67:

> 65: 
> 66:     /**
> 67:      * {@return for an {@code invokeinterface}, the {@code count} value, as defined in {@jvms 6.5}}

Suggestion:

     * {@return the {@code count} value of an {@code invokeinterface} instruction, as defined in {@jvms 6.5}}

src/java.base/share/classes/java/lang/classfile/package-info.java line 254:

> 252:  * No consistency checks are performed while building or transforming classfiles
> 253:  * (except for null arguments checks). All builders and classfile elements factory
> 254:  * methods accepts provided information without implicit validation.

Suggestion:

 * methods accepts the provided information without implicit validation.

src/java.base/share/classes/java/lang/classfile/package-info.java line 255:

> 253:  * (except for null arguments checks). All builders and classfile elements factory
> 254:  * methods accepts provided information without implicit validation.
> 255:  * However fatal inconsistencies (like for example invalid code sequence or

Suggestion:

 * However, fatal inconsistencies (like for example invalid code sequence or

src/java.base/share/classes/java/lang/classfile/package-info.java line 259:

> 257:  * the classfile building process.
> 258:  * 

> 259:  * Basic syntax control can be achieved using symbolic descriptors. For example

What does "syntax control" mean? The concept is used, but not defined, in the javadoc. (I presume we mean eg.g. turning String into `Ljava/lang/String;`)

src/java.base/share/classes/java/lang/classfile/package-info.java line 266:

> 264:  * On the other hand it is possible to use builders methods and factories accepting
> 265:  * constant pool entries to avoid any form of syntax control. Constant pool entries
> 266:  * can be constructed from raw values, where no syntax control is in charge.

Suggestion:

 * can be constructed from raw values, with no additional syntactic checks.

src/java.base/share/classes/java/lang/classfile/package-info.java line 273:

> 271:  * 

> 272:  * More complex verification of a classfile can be achieved by explicit invocation
> 273:  * of {@link java.lang.classfile.ClassModel#verify}.

Aren't part of verification also ran as part of generating stackmaps (unless stackmap inference is disabled) ? Should it be mentioned here?

src/java.base/share/classes/java/lang/classfile/package-info.java line 386:

> 384:  * resulting in many unreferenced constant pool entries.
> 385:  *
> 386:  * 
Transformation handling of unknown classfile elements from a future


>From a future... ? JDK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342714653
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342716987
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342720961
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342724684
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342725264
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342726203
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342728341
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342730435
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342730871

From asotona at openjdk.org  Mon Oct  2 14:01:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:01:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:24:49 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 596:
> 
>> 594:      * @param type the object type
>> 595:      * @return this builder
>> 596:      * @throws IllegalArgumentException if {@code type} represents a primitive type
> 
> What about arrays? (ClassDesc has an `isArray` predicate too). This probably applies to other methods too.

Test for arrays is not performed. The only constraint here is ability to construct constant pool class entry, which is not possible from a primitive type.
The library does only bare minimal consistency checks and proposal for additional constraints should be discussed at the mailing list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342731348

From asotona at openjdk.org  Mon Oct  2 14:01:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:01:24 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
 <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
Message-ID: 

On Mon, 2 Oct 2023 13:23:00 GMT, Maurizio Cimadamore  wrote:

>> src/java.base/share/classes/java/lang/classfile/ClassTransform.java line 164:
>> 
>>> 162: 
>>> 163:     /**
>>> 164:      * @implSpec
>> 
>> Should these overridden method have `@inheritDoc` ? If not, their javadoc won't show much, I believe. (same might be true for other methods)
>
> (To be precise - the javadoc says "Description copied from interface: ClassFileTransform") - just make sure that's what you want.

The javadoc shows what is expected, so I'm not sure `@inheritDoc` is still required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342720357

From mcimadamore at openjdk.org  Mon Oct  2 14:01:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:01:36 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:50:17 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java line 67:
> 
>> 65: 
>> 66:     /**
>> 67:      * {@return for an {@code invokeinterface}, the {@code count} value, as defined in {@jvms 6.5}}
> 
> Suggestion:
> 
>      * {@return the {@code count} value of an {@code invokeinterface} instruction, as defined in {@jvms 6.5}}

What does this return for something that is not `invokeinterface` ? Do we infer the count from the descriptor? Or do we return -1 ? This should probably be reflected in the javadoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342721975

From asotona at openjdk.org  Mon Oct  2 14:20:17 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:20:17 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v4]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <9AHA5Q0Hh40IVCHedBXufW0fbphSk_SrcdHQKhpHthI=.5128350b-ac18-4f02-a3a2-18a72a2a97e5@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - fixing javadoc
 - fixing javadoc
 - fixing javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/df02df8f..75be7e89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=02-03

  Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  2 14:20:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:20:24 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: <-TSw34evJdBqh-rwtz2D0KxhdzD4EaiEMjuYY3MIsMs=.f4c7571b-4e46-421e-a339-070843fbcc3a@github.com>

On Mon, 2 Oct 2023 13:26:38 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/CodeTransform.java line 101:
> 
>> 99: 
>> 100:     /**
>> 101:      * @implSpec The default implementation returns a resolved transform;
> 
> `... returns a resolved transform that is bound to the given code builder`
> or
> `... returns a resolved transform bound to the given code builder`

Fixed, thanks.

> src/java.base/share/classes/java/lang/classfile/MethodSignature.java line 59:
> 
>> 57: 
>> 58:     /**
>> 59:      * {@return method signature for a raw (no generic information) method descriptor}
> 
> Isn't this missing an article - e.g. `return the method signature` or `return a method signature` ?

Fixed, thanks.

> src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 310:
> 
>> 308:          * @param implClasses the implementation classes
>> 309:          * @return this builder
>> 310:          * @throws IllegalArgumentException if {@code service} or any of the {@code implClasses} represents a primitive type
> 
> Javadoc tip (not that you should use that here) - if the thrown clause becomes too complex, you can also split it into multiple `throws IllegalArgumentException`. Sometimes that can improve readability.

Thanks!

> src/java.base/share/classes/java/lang/classfile/attribute/ModuleResolutionAttribute.java line 75:
> 
>> 73:      *  The value of the resolution_flags item is a mask of flags used to denote
>> 74:      *  properties of module resolution. The flags are as follows:
>> 75:      * 
 {@code
> 
> Why not a snippet?

It is a citation from the spec, not sure a snippet would be appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342738626
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342745504
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342745325
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342748330

From asotona at openjdk.org  Mon Oct  2 14:20:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:20:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
 <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
Message-ID: 

On Mon, 2 Oct 2023 13:29:59 GMT, Maurizio Cimadamore  wrote:

>> src/java.base/share/classes/java/lang/classfile/FieldTransform.java line 116:
>> 
>>> 114: 
>>> 115:     /**
>>> 116:      * @implSpec The default implementation returns a resolved transform with all
>> 
>> Perhaps lose the `all its parts` - not sure that makes the comment any clearer?
>
> I've noted the same pattern in other similar methods

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342742531

From mcimadamore at openjdk.org  Mon Oct  2 14:20:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:20:30 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: <0CTJUB-_AW4VNsNoglFLvyoabSIgZEESnJCYfm029gE=.818a972c-a5c1-4654-bbcd-117c5a9107aa@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

src/java.base/share/classes/java/lang/classfile/package-info.java line 389:

> 387:  * To achieve stability of transformations in future JDK releases it is desired
> 388:  * to set appropriate response to potential new classfile elements appearing.
> 389:  * Transformation designed to handle all situation should be implemented strict way,

"handle all situations" - I couldn't make much sense of it. I only got it when reading the text that follows, which says "transformation selectively interested in ...". This para should be rephrased for better clarity. E.g.
"Classfile transforms that are interested in consuming _all_ classfile elements should be implemented in a strict fashion, so that new exceptions will be issued, should a new and unknown classfile element appear ... Conversely, classfile transforms that are only interested in consuming a portion of classfile elements do not need to concern with new and unknown classfile elements ... because ... "

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342737274

From asotona at openjdk.org  Mon Oct  2 14:25:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:25:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v5]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/classfile/components/ClassPrinter.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/75be7e89..ea31ec98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  2 14:29:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:29:56 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v6]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/ea31ec98..dc2dfd30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  2 14:42:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:42:55 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v7]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/dc2dfd30..bd84bf93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  2 14:43:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:43:02 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:40:40 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/components/CodeRelabeler.java line 71:
> 
>> 69:      * Creates a new instance of CodeRelabeler using provided {@link java.util.function.BiFunction}
>> 70:      * to re-label the code.
>> 71:      * @param mapFunction function remapping labels
> 
> I found this a bit hard to read. Maybe expand to "function for remapping labels in the source code model", or something similar

Fixed, thanks.

> src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java line 158:
> 
>> 156:      */
>> 157:     default ClassEntry classEntry(ClassDesc classDesc) {
>> 158:         if (requireNonNull(classDesc).isPrimitive()) {
> 
> It is not clear to me as to whether all the methods in the API deal with null correctly. What we did for FFM, assuming that the classfile API is also null-hostile by default, was to add a single test which would try to call all API methods and looking for NPEs:
> 
> https://github.com/openjdk/jdk/blob/2637e8ddc4ffe102418139f501fc0be8e9c5317b/test/jdk/java/foreign/TestNulls.java#L80
> 
> This test has saved us many times when adding/changing API methods.

Good point, thanks.
I've create new RFE https://bugs.openjdk.org/browse/JDK-8317356 because the test would not be so simple to cover all ClassFile API in different situations (for example different builders implementations based on the actual context).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342777997
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342775179

From mcimadamore at openjdk.org  Mon Oct  2 14:45:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:45:31 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

test/langtools/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java line 107:

> 105:     }
> 106: 
> 107: // this version of the code can be used when ClassFile API in not in a preview

Do you want to keep these commented lines? I'm fine (as it seems like you saved the code that was there before, for future reference). I'm just asking as this is a biggie PR, in case something went amiss.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342783513

From abimpoudis at openjdk.org  Mon Oct  2 14:48:04 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 2 Oct 2023 14:48:04 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v2]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
 
Message-ID: 

On Fri, 29 Sep 2023 16:17:06 GMT, Raffaello Giulietti  wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Raffaello Giulietti 
>
> I just had a reading at the `ExactnessMethods` class. From that limited perspective, the methods mentioned above seem redundant.
> But if their removal would make other parts more complex, that's a good reason to keep them.

Pushed an update that removes the methods you pointed out @rgiulietti at the cost of a little duplication between Lower and SwitchBootstraps. Thx for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1743148778

From abimpoudis at openjdk.org  Mon Oct  2 14:47:59 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 2 Oct 2023 14:47:59 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
 - Implement type pairs to exactnessMethod name
 - Apply suggestions from code review
   
   Co-authored-by: Raffaello Giulietti 
 - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/1ae06ac8..ad6071b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=01-02

  Stats: 28829 lines in 719 files changed: 17870 ins; 8464 del; 2495 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From mcimadamore at openjdk.org  Mon Oct  2 14:49:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:49:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:40:49 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> test/langtools/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java line 107:
> 
>> 105:     }
>> 106: 
>> 107: // this version of the code can be used when ClassFile API in not in a preview
> 
> Do you want to keep these commented lines? I'm fine (as it seems like you saved the code that was there before, for future reference). I'm just asking as this is a biggie PR, in case something went amiss.

That said, if tests with such usages are not many, we could also consider adding enable-preview to the tests, and just use the new API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342789740

From dl at openjdk.org  Mon Oct  2 14:51:01 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 2 Oct 2023 14:51:01 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v45]
In-Reply-To: 
References: 
Message-ID: <6e0dLqZmhqs4WmoTc9G-MH4jymBpa663lwgi30Qil6U=.ae1ce208-724d-405a-ab8f-c9d49672d366@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/71ab0a2f..078655ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=43-44

  Stats: 57 lines in 1 file changed: 20 ins; 29 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From mcimadamore at openjdk.org  Mon Oct  2 14:59:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:59:28 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

test/langtools/tools/javac/classfiles/attributes/SourceFile/NoSourceFileAttribute.java line 52:

> 50:         assertNull(
> 51:                 ClassFile.of().parse(getClassFile(NoSourceFileAttribute.class).toPath()).findAttribute(Attributes.SOURCE_FILE).orElse(null),
> 52:                 "ClassFile should have no SourceFile attribute when compiled without debug information.");

Not sure if replacing the camel case ClassFile in the assertion message is what you wanted here

test/langtools/tools/javac/classfiles/attributes/SourceFile/SourceFileTestBase_legacy.java line 45:

> 43:  * @see #compileAndTest
> 44:  */
> 45: public class SourceFileTestBase_legacy extends TestBase {

Why is this called "legacy" ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342796933
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342798443

From mcimadamore at openjdk.org  Mon Oct  2 14:59:29 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:59:29 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:52:58 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> test/langtools/tools/javac/classfiles/attributes/SourceFile/SourceFileTestBase_legacy.java line 45:
> 
>> 43:  * @see #compileAndTest
>> 44:  */
>> 45: public class SourceFileTestBase_legacy extends TestBase {
> 
> Why is this called "legacy" ?

Uhmm is this to be used in tests to be compiled against a JDK release where no classfile API is available?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342802259

From dl at openjdk.org  Mon Oct  2 15:04:17 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 2 Oct 2023 15:04:17 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v45]
In-Reply-To: <6e0dLqZmhqs4WmoTc9G-MH4jymBpa663lwgi30Qil6U=.ae1ce208-724d-405a-ab8f-c9d49672d366@github.com>
References: 
 <6e0dLqZmhqs4WmoTc9G-MH4jymBpa663lwgi30Qil6U=.ae1ce208-724d-405a-ab8f-c9d49672d366@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:51:01 GMT, Doug Lea 
 wrote:

>> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
>> 
>> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

Backport instructions:
1. change all methods with new Since tags to nonpublic
2. Comment/uncomment ForkJonPool.invokeAll according to instructions there (the new version fixes an ExecutorService signature incompatibility, at the price of a backwards incompatibility in throws clause.)
3. It is possible that some (incorrect) java/util/concurrent/tck tests will fail, in which case replace with new versions

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

PR Comment: https://git.openjdk.org/jdk/pull/14301#issuecomment-1743185939

From mcimadamore at openjdk.org  Mon Oct  2 15:10:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 15:10:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

Completed first pass on the PR. Everything looks ok modulo some minor nits. I like the new came case name for ClassFile :-)

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

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1652950261

From asotona at openjdk.org  Mon Oct  2 15:14:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 15:14:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:56:11 GMT, Maurizio Cimadamore  wrote:

>> test/langtools/tools/javac/classfiles/attributes/SourceFile/SourceFileTestBase_legacy.java line 45:
>> 
>>> 43:  * @see #compileAndTest
>>> 44:  */
>>> 45: public class SourceFileTestBase_legacy extends TestBase {
>> 
>> Why is this called "legacy" ?
>
> Uhmm is this to be used in tests to be compiled against a JDK release where no classfile API is available?

We need these "legacy" copies while ClassFile API is a preview feature.
Some of the tests require to specify compilation target other than 22 and it is not possible to combine it with enabled preview switch.
Fortunately it affects only very few from the hundreds of tests already converted to ClassFile API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342820255

From vromero at openjdk.org  Mon Oct  2 15:20:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Oct 2023 15:20:32 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 07:18:19 GMT, Adam Sotona  wrote:

>> src/java.base/share/classes/java/lang/classfile/AnnotationElement.java line 34:
>> 
>>> 32: import jdk.internal.javac.PreviewFeature;
>>> 33: 
>>> 34: /**
>> 
>> shouldn't we have the preview header applied to all these compilation units?:
>> 
>> 
>> {@preview Associated with pattern matching for instanceof, a preview feature of the Java language.
>
> I'm not aware of preview javadoc tag, could you point me to an example?

nvm, I was rechecking JEP 12, this javadoc should now be generated automatically so we are good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342825999

From asotona at openjdk.org  Mon Oct  2 15:20:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 15:20:33 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:45:52 GMT, Maurizio Cimadamore  wrote:

>> test/langtools/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java line 107:
>> 
>>> 105:     }
>>> 106: 
>>> 107: // this version of the code can be used when ClassFile API in not in a preview
>> 
>> Do you want to keep these commented lines? I'm fine (as it seems like you saved the code that was there before, for future reference). I'm just asking as this is a biggie PR, in case something went amiss.
>
> That said, if tests with such usages are not many, we could also consider adding enable-preview to the tests, and just use the new API.

Yes, that is proposed temporary solution to do not loose already converted code while ClassFile API is in preview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342824044

From jvernee at openjdk.org  Mon Oct  2 16:07:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 2 Oct 2023 16:07:09 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v33]
In-Reply-To: 
References: 
Message-ID: <0r5bNt-ez79b7DrOJUuHCPguBQkn3MtEJdoQFqVuWxA=.86265508-9e7d-4fab-a851-35c5c138255d@github.com>

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Remove PIP annotation from jdk.incubator.vector

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/17dacbbd..cc89a519

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=31-32

  Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

PR: https://git.openjdk.org/jdk/pull/15103

From naoto at openjdk.org  Mon Oct  2 17:06:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 2 Oct 2023 17:06:52 GMT
Subject: RFR: 8317265: ListFormat::format specification could be made clearer
 regarding handling IllegalArgumentException.
Message-ID: 

A simple clarification of the conditions for throwing an IAE.

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

Commit messages:
 - initial commit

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

PR: https://git.openjdk.org/jdk/pull/16013

From mcimadamore at openjdk.org  Mon Oct  2 17:31:34 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 17:31:34 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti 
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5052:

> 5050: 
> 5051:         return (source.isPrimitive() && target.isPrimitive()) &&
> 5052:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||

Does this mean that `byte` -> `char` is not exact? Aren't both integral types, thus invalidating `widening from one integral type to another` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4154:

> 4152:     public void visitTypeTest(JCInstanceOf tree) {
> 4153:         Type exprtype = attribExpr(tree.expr, env);
> 4154:         if(!allowPrimitivePatterns) {

nit: space missing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1342954914
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1342958314

From mcimadamore at openjdk.org  Mon Oct  2 17:37:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 17:37:06 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti 
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 735:

> 733:                 }
> 734:             }
> 735:             if (tree.selector.type.hasTag(TypeTag.BOOLEAN)) {

I would have expected true/false to be treated more or less like enum constants when it came to exhaustiveness? E.g. boolean is similar to an enum type that only has two options (or, if you will, a sealed type with two permitted subtypes). So, IMHO the treatment for booleans should happen in the `exhausts` method - and this method should be left very simple (possibly unchanged?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1342970659

From mcimadamore at openjdk.org  Mon Oct  2 17:45:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 17:45:21 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti 
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 770:

> 768:         PrimitiveGenerator primitiveGenerator = new PrimitiveGenerator();
> 769:         primitiveGenerator.assembleSig(primitiveType);
> 770:         return new Symbol.DynamicVarSymbol(names.fromString(primitiveGenerator.sb.toString()),

Why do we need a condy to generate a `Class` object for a type we know statically? E.g. will this not be resolved to .class ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1342978008

From luke.k.xu at hotmail.com  Mon Oct  2 17:47:12 2023
From: luke.k.xu at hotmail.com (=?UTF-8?B?6K646L2y?=)
Date: Tue, 03 Oct 2023 01:47:12 +0800
Subject: Bug Report [jpackage Packaging Issue]
References: 
Message-ID: 

luke.k.xu at hotmail.com ???luke.k.xu at hotmail.com ---- ????? ---- ??? Andrew H. Gross ?? 2023?09?30? 08:40 ??? ?? ??? vuln-report at openjdk.org ?? Re: Bug Report [jpackage Packaging Issue] Hello, I read your problem description.? As I understand it, this does not appear to be a vulnerability. If you want to report a bug, then this site[0] is the best.? This mailing list[1] is the one that covers jpackage. Thank you, Andrew Gross --- [0] https://bugreport.java.com/bugreport/ [1] core-libs-dev at openjdk.org On 9/29/2023 10:12 AM, ?? wrote: check out the attachment for more details Subject: Bug Report: [jpackage Packaging Bug] Dear OpenJDK Team, I would like to report a bug I encountered while using OpenJDK. Below are the details of the issue: **Problem Description:** I'm attempting to package my JavaFX application, but when I reach the crucial step (jpackage), the packaging process does not behave as expected. **Version Information:** - OpenJDK version "21" 2023-09-19 - OpenJDK Runtime Environment (build 21+35-2513) - OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing) **Minimal Reproducible Example:** MY project address: https://gitee.com/jcnc-org/JNotepad I'm trying to package my JavaFX application. First, I use jlink as follows: ```  ? ? org.openjfx ? ? javafx-maven-plugin ? ? 0.0.8 ? ?  ? ? ? ?  ? ? ? ? ? ?  ? ? ? ? ? ? default-cli ? ? ? ? ? ?  ? ? ? ? ? ? ? ? org.jcnc.jnotepad/org.jcnc.jnotepad.LunchApp ? ? ? ? ? ? ? ? JNotepad ? ? ? ? ? ? ? ? JNotepad ? ? ? ? ? ? ? ? true ? ? ? ? ? ? ? ? true ? ? ? ? ? ? ? ? true ? ? ? ? ? ? ? ? 2 ? ? ? ? ? ?  ? ? ? ?  ? ?   ``` Then, when I use the following command: ``` jpackage ` --name JNotepad ` --type app-image ` -m org.jcnc.jnotepad/org.jcnc.jnotepad.LunchApp ` --runtime-image .\target\JNotepad\ ` --icon src/main/resources/img/icon.ico ` --app-version 1.1.13 ` --vendor "JCNC" ``` **Expected and Actual Behavior:** jpackage fails to include the JNotepad.ico file in the folder. - Failure Case (no JNotepad.ico): - Expected Behavior (with Jdk 20 and earlier, where JNotepad.ico is included): **Error Logs:** None **Additional Context Information:** This issue occurs with OpenJDK-17 or any JDK versions before 21. For example: ? ? openjdk version "17.0.2" 2022-01-18 ? ? OpenJDK Runtime Environment (build 17.0.2+8-86) ? ? OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing) System Information: ? ? Hostname: ? ? ? ? LUKE ? ? OS Name: ? ? ? ? ? Microsoft Windows 11 Home Chinese Edition ? ? OS Version: ? ? ? ?10.0.22621 Not Available Build 22621 ? ? OS Manufacturer: ? Microsoft Corporation ? ? OS Configuration: ?Standalone Workstation ? ? OS Build Type: ? ? Multiprocessor Free ? ? Registered Owner: ?luke ? ? Registered Organization: Not Available ? ? Product ID: ? ? ? ?00342-35838-97577-AAOEM ? ? Initial Install Date: March 14, 2023, 21:45:39 ? ? System Boot Time: ?September 30, 2023, 0:11:06 ? ? System Manufacturer: HUAWEI ? ? System Model: ? ? ?KLVC-WXX9 ? ? System Type: ? ? ? x64-based PC ? ? Processor: ? ? ? ? 1 Processor Installed. ? ? ? ? ? ? ? ? ? ? [01]: Intel64 Family 6 Model 142 Stepping 12 GenuineIntel ~1803 Mhz ? ? BIOS Version: ? ? ?HUAWEI 1.30, February 16, 2022 ? ? Windows Directory: C:\WINDOWS ? ? System Directory: ?C:\WINDOWS\system32 ? ? Boot Device: ? ? ? \Device\HarddiskVolume1 ? ? System Locale: ? ? zh-cn; Chinese (China) ? ? Input Locale: ? ? ?zh-cn; Chinese (China) ? ? Time Zone: ? ? ? ? (UTC+08:00) Beijing, Chongqing, Hong Kong SAR, Urumqi ? ? Total Physical Memory: 16,212 MB ? ? Available Physical Memory: 3,568 MB ? ? Virtual Memory: ? ?Maximum Size: 25,940 MB ? ? Virtual Memory: ? ?Available: 6,220 MB ? ? Virtual Memory: ? ?In Use: 19,720 MB ? ? Page File Location: C:\pagefile.sys ? ? Domain: ? ? ? ? ? ?WORKGROUP ? ? Logon Server: ? ? ?\\LUKE ? ? Hotfixes: ? ? ? ? ?4 Hotfixes Installed. ? ? ? ? ? ? ? ? ? ? [01]: KB5029921 ? ? ? ? ? ? ? ? ? ? [02]: KB5012170 ? ? ? ? ? ? ? ? ? ? [03]: KB5030219 ? ? ? ? ? ? ? ? ? ? [04]: KB5028756 ? ? Network Cards: ? ? 4 Network Adapters Installed. ? ? ? ? ? ? ? ? ? ? [01]: Intel(R) Wireless-AC 9560 160MHz ? ? ? ? ? ? ? ? ? ? ? ? ? ? Connection Name: WLAN ? ? ? ? ? ? ? ? ? ? ? ? ? ? DHCP Enabled: Yes ? ? ? ? ? ? ? ? ? ? ? ? ? ? DHCP Server: 192.168.0.1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? IP Addresses ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [01]: 192.168.0.106 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [02]: fe80::b6da:a7b4:e0dc:3ef5 ? ? ? ? ? ? ? ? ? ? [02]: Bluetooth Device (Personal Area Network) ? ? ? ? ? ? ? ? ? ? ? ? ? ? Connection Name: Bluetooth Network Connection ? ? ? ? ? ? ? ? ? ? ? ? ? ? Status: Media disconnected ? ? ? ? ? ? ? ? ? ? [03]: VirtualBox Host-Only Ethernet Adapter ? ? ? ? ? ? ? ? ? ? ? ? ? ? Connection Name: Ethernet 2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? DHCP Enabled: No ? ? ? ? ? ? ? ? ? ? ? ? ? ? IP Addresses ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [01]: 192.168.56.1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [02]: fe80::20aa:46cf:9661:52f2 ? ? ? ? ? ? ? ? ? ? [04]: Wintun Userspace Tunnel ? ? ? ? ? ? ? ? ? ? ? ? ? ? Connection Name: Clash ? ? ? ? ? ? ? ? ? ? ? ? ? ? DHCP Enabled: No ? ? ? ? ? ? ? ? ? ? ? ? ? ? IP Addresses ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [01]: 198.18.0.1 ? ? Hyper-V Requirements: A virtual machine monitor program has been detected. Hyper-V features are not displayed. **Steps:** 1. Run jlink. 2. Run jpackage. 3. Observe the bug. This bug is consistently reproducible in my environment. Please let me know if you need any further information to investigate and resolve this issue. Thank you for your attention to this matter. Sincerely, Ke Xu Email: luke.k.xu at hotmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 7427 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image-1.png
Type: image/png
Size: 9485 bytes
Desc: not available
URL: 

From dl at openjdk.org  Mon Oct  2 18:13:02 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 2 Oct 2023 18:13:02 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v46]
In-Reply-To: 
References: 
Message-ID: 

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

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

 - Merge branch 'openjdk:master' into JDK-8288899
 - cleanup
 - Merge branch 'openjdk:master' into JDK-8288899
 - refactor termination
 - Undo stray edit
 - Streamline push; add redundant interrupts
 - Merge branch 'openjdk:master' into JDK-8288899
 - Possibly re-interrupt when stopping
 - more conservative resize checks
 - Merge branch 'openjdk:master' into JDK-8288899
 - ... and 84 more: https://git.openjdk.org/jdk/compare/f5531b24...01e31edd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/078655ed..01e31edd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=44-45

  Stats: 1135 lines in 50 files changed: 802 ins; 176 del; 157 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From naoto at openjdk.org  Mon Oct  2 18:26:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 2 Oct 2023 18:26:54 GMT
Subject: RFR: JDK-8315064: j.text.ChoiceFormat provides no specification on
 quoting behavior
In-Reply-To: 
References: 
Message-ID: 

On Fri, 29 Sep 2023 20:46:44 GMT, Justin Lu  wrote:

> Please review this PR and which adjusts the pattern section of java.text.ChoiceFormat to specify the single quote behavior within a String pattern.
> 
> The other Format classes that take a String pattern such as DecimalFormat, CompactNumberFormat, and MessageFormat all provide specification on single quote behavior within a String pattern. ChoiceFormat should have similar specification.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15994#pullrequestreview-1653267645

From mark.reinhold at oracle.com  Mon Oct  2 18:31:22 2023
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Mon, 2 Oct 2023 18:31:22 +0000
Subject: Adding appendHex method to StringBuilder
In-Reply-To: <0a97f39e-953d-4530-add3-29560d29303d.shaojin.wensj@alibaba-inc.com>
References: 
 
 
 <0a97f39e-953d-4530-add3-29560d29303d.shaojin.wensj@alibaba-inc.com>
Message-ID: <20231002143119.431457751@eggemoggin.niobe.net>

2023/10/2 10:01:10 -0400, shaojin.wensj at alibaba-inc.com:
> StringTemplate is great and I wish I can submit PR to improve it. But
> I still think StringBuilder.appendHex is a basic API, not a formatted
> API. Just like Integer.toHexString and Long.toHexString, they are very
> commonly used and should be built-in.

Think carefully about where this leads.

One of the keys to making an API understandable is to have each class or
interface express a single concept with a single purpose.  This allows
developers to build up clean mental models of which part of an API is
used for which functionality, and then cleanly compose them.

When we add convenience methods to a class or interface, we pollute its
design.  If we do so whenever we identify a common method combination
then the class or interface eventually becomes a grab-bag of methods
that perform the functions of two (or three or four ...) classes.  This
muddies the conceptual model, making the API more difficult to use.

Adding convenience methods is, sometimes, justifiable.  The fact that a
particular method pairing is common in a single code base -- even if
that code base is the JDK itself -- is far from a compelling argument.

- Mark

From duke at openjdk.org  Mon Oct  2 20:56:58 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Mon, 2 Oct 2023 20:56:58 GMT
Subject: Integrated: 8317034: Remove redundant type cast in the
 java.util.stream package
In-Reply-To: 
References: 
Message-ID: 

On Wed, 27 Sep 2023 08:50:20 GMT, Mourad Abbay  wrote:

> Remove redundant type cast in the java.util.stream package.

This pull request has now been integrated.

Changeset: ad81abd2
Author:    Mourad Abbay 
Committer: Paul Sandoz 
URL:       https://git.openjdk.org/jdk/commit/ad81abd2dbddc47d57eceb4d90fe615a6e986fe5
Stats:     5 lines in 3 files changed: 0 ins; 0 del; 5 mod

8317034: Remove redundant type cast in the java.util.stream package

Reviewed-by: psandoz

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

PR: https://git.openjdk.org/jdk/pull/15942

From bpb at openjdk.org  Mon Oct  2 23:12:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 2 Oct 2023 23:12:24 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v6]
In-Reply-To: 
References: 
Message-ID: 

> In the Windows implementation of java.io.File.getCanonicalPath, strip any long path or UNC prefix before canonicalizing the remainder of the pathname.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8287843: remove stripLongOrUNCPrefix() except in normalize()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15603/files
  - new: https://git.openjdk.org/jdk/pull/15603/files/63e2c5c2..d05eba05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=04-05

  Stats: 60 lines in 1 file changed: 23 ins; 32 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15603/head:pull/15603

PR: https://git.openjdk.org/jdk/pull/15603

From jiangli at openjdk.org  Tue Oct  3 02:26:15 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 3 Oct 2023 02:26:15 GMT
Subject: RFR: 8316923: Add DEF_STATIC_JNI_OnLoad for librmi
Message-ID: 

Please help review this trivial change that adds missing DEF_STATIC_JNI_OnLoad for librmi.

Thanks

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

Commit messages:
 - 8316923: Add DEF_STATIC_JNI_OnLoad for librmi

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

PR: https://git.openjdk.org/jdk/pull/16020

From david.holmes at oracle.com  Tue Oct  3 02:36:22 2023
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Oct 2023 12:36:22 +1000
Subject: An error will be reported when compiling the master on OrangeP5
 Plus
In-Reply-To: <78fec0b7-7ee1-4f66-99c3-2fb746ea8e6f.shaojin.wensj@alibaba-inc.com>
References: <78fec0b7-7ee1-4f66-99c3-2fb746ea8e6f.shaojin.wensj@alibaba-inc.com>
Message-ID: <8595c50e-134a-4dd4-8b3c-a9232c60438e@oracle.com>

Moving to hotspot-runtime-dev as this is a VM crash with compressed Oops.

David

On 1/10/2023 10:49 am, ???(??) wrote:
> 
> An error will be reported when compiling the master on OrangeP5 Plus 
> (http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html ), but the compilation of the 21u version is passed.
> 
> The error message is as follows:
> 
> ```
> Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
> Creating support/classlist.jar
> /usr/bin/bash: line 15: 854142 Aborted                 
> /root/git/jdk/build/linux-aarch64-server-release/support/interim-image/bin/java -XX:DumpLoadedClassList=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.raw.2 -XX:SharedClassListFile=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.interim -XX:SharedArchiveFile=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.jsa -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -Duser.language=en -Duser.country=US --module-path /root/git/jdk/build/linux-aarch64-server-release/support/classlist.jar -cp /root/git/jdk/build/linux-aarch64-server-release/support/classlist.jar build.tools.classlist.HelloClasslist 2> /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/stderr > /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/default_jli_trace.txt
> ERROR: Failed to generate link optimization data. This is likely a 
> problem with the newly built JVM/JDK.
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #? Internal Error (macroAssembler_aarch64.cpp:4654), pid=854142, tid=854143
> #? guarantee((shifted_base & 0xffff0000ffffffff) == 0) failed: 
> compressed class base bad alignment
> #
> # JRE version:? (22.0) (build )
> # Java VM: OpenJDK 64-Bit Server VM (22-internal-adhoc.root.jdk, mixed 
> mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, 
> linux-aarch64)
> # Problematic frame:
> # V? [libjvm.so+0xae20d0]  
> MacroAssembler::decode_klass_not_null(Register, Register)+0x250
> #
> # No core dump will be written. Core dumps have been disabled. To enable 
> core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /root/git/jdk/make/hs_err_pid854142.log
> #
> #
> gmake[3]: *** [GenerateLinkOptData.gmk:71: 
> /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist] Error 134
> gmake[2]: *** [make/Main.gmk:649: generate-link-opt-data] Error 2
> gmake[2]: *** Waiting for unfinished jobs....
> ERROR: Build failed for target 'images' in configuration 
> 'linux-aarch64-server-release' (exit code 2)
> Stopping javac server
> No indication of failed target found.
> HELP: Try searching the build log for '] Error'.
> HELP: Run 'make doctor' to diagnose build problems.
> make[1]: *** [/root/git/jdk/make/Init.gmk:323: main] Error 2
> make: *** [/root/git/jdk/make/Init.gmk:189: images] Error 2
> ```
> 
> 
> 
> 
> 

From alanb at openjdk.org  Tue Oct  3 06:12:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Oct 2023 06:12:10 GMT
Subject: RFR: 8316923: Add DEF_STATIC_JNI_OnLoad for librmi
In-Reply-To: 
References: 
Message-ID: 

On Tue, 3 Oct 2023 02:19:00 GMT, Jiangli Zhou  wrote:

> Please help review this trivial change that adds missing DEF_STATIC_JNI_OnLoad for librmi.
> 
> Thanks

Surprised this one didn't have DEF_STATIC_JNI_OnLoad already. Change looks okay, can you update the copyright date before integrating.

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

PR Review: https://git.openjdk.org/jdk/pull/16020#pullrequestreview-1654413018

From alanb at openjdk.org  Tue Oct  3 06:29:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Oct 2023 06:29:22 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v6]
In-Reply-To: 
References: 
 
Message-ID: <_zYTDBBbzjYoHEbRjZkFLmx1jZnhlzHN-EhVRtnIYOc=.06db1163-8c79-459a-a37b-2bbad0771f60@github.com>

On Mon, 2 Oct 2023 23:12:24 GMT, Brian Burkhalter  wrote:

> remove stripLongOrUNCPrefix() except in normalize()

I haven't had time to look at the test changes yet but the I think the code changes look okay so I think go ahead and create the CSR as this behavior change will need to be tracked.

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

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1744288471

From davidalayachew at gmail.com  Tue Oct  3 07:09:22 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 3 Oct 2023 03:09:22 -0400
Subject: New method on java.util.function.Function -- ternary method
Message-ID: 

Hello all,

I have an idea that I want to run by you all -- a new method on
java.util.function.Function to capture ternary operations.

Here is a mockup of what I wanted to do.

>
> import java.util.function.Function;
>
> @FunctionalInterface
> public interface Function2 extends Function
> {
>
>    public static  Function ternary
>    (
>        Predicate test,
>        Function trueOutput,
>        Function falseOutput
>    )
>    {
>
>       return
>           (I input) ->
>               test.test(input)
>               ? trueOutput.apply(input)
>               : falseOutput.apply(input)
>               ;
>
>    }
>
> }
>

I think this is useful for a few reasons.

 * This composes, just like the ternary operator itself.

 * It pairs well with Function.identity() and method references to clearly
(but concisely) communicate intent.

 * Ternary operations are common, so this will find great use by developers
of all sorts.

There is at least one part I don't quite like about this design - what if
one (or both!) of your outputs is not a functional transformation of the
input?

For example, String username = id.isBlank() ? "UNKNOWN" : lookup(id);

Obviously, this is easy to work around - simply ignore the input of the
function. But you lose clarity and simplicity that way. I would put a note
in the javadoc that says that this method should only be used in instances
where both outputs are a functional transformation of the input. That way,
intent is clarified. But if we go that route, maybe this function should
get a better name to capture that? testThenApply? ternaryTransform?
ternaryApply?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From davidalayachew at gmail.com  Tue Oct  3 07:13:57 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 3 Oct 2023 03:13:57 -0400
Subject: New method on java.util.function.Function -- ternary method
In-Reply-To: 
References: 
Message-ID: 

Whoops, bad import.

Please replace the following line with the one after it.

> import java.util.function.Function;

> import java.util.function.*;

On Tue, Oct 3, 2023 at 3:09?AM David Alayachew 
wrote:

> Hello all,
>
> I have an idea that I want to run by you all -- a new method on
> java.util.function.Function to capture ternary operations.
>
> Here is a mockup of what I wanted to do.
>
> >
> > import java.util.function.Function;
> >
> > @FunctionalInterface
> > public interface Function2 extends Function
> > {
> >
> >    public static  Function ternary
> >    (
> >        Predicate test,
> >        Function trueOutput,
> >        Function falseOutput
> >    )
> >    {
> >
> >       return
> >           (I input) ->
> >               test.test(input)
> >               ? trueOutput.apply(input)
> >               : falseOutput.apply(input)
> >               ;
> >
> >    }
> >
> > }
> >
>
> I think this is useful for a few reasons.
>
>  * This composes, just like the ternary operator itself.
>
>  * It pairs well with Function.identity() and method references to clearly
> (but concisely) communicate intent.
>
>  * Ternary operations are common, so this will find great use by
> developers of all sorts.
>
> There is at least one part I don't quite like about this design - what if
> one (or both!) of your outputs is not a functional transformation of the
> input?
>
> For example, String username = id.isBlank() ? "UNKNOWN" : lookup(id);
>
> Obviously, this is easy to work around - simply ignore the input of the
> function. But you lose clarity and simplicity that way. I would put a note
> in the javadoc that says that this method should only be used in instances
> where both outputs are a functional transformation of the input. That way,
> intent is clarified. But if we go that route, maybe this function should
> get a better name to capture that? testThenApply? ternaryTransform?
> ternaryApply?
>
> Thank you for your time and help!
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From asotona at openjdk.org  Tue Oct  3 07:40:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 07:40:55 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v8]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/bd84bf93..8fd17c13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From gbarany at openjdk.org  Tue Oct  3 07:55:21 2023
From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany)
Date: Tue, 3 Oct 2023 07:55:21 GMT
Subject: RFR: 8315680: java/lang/ref/ReachabilityFenceTest.java should run with
 -Xbatch
Message-ID: 

This test requires certain methods to be compiled, but without `-Xbatch` the compiler races against the test code, which can lead to intermittent failures.

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

Commit messages:
 - 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch

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

PR: https://git.openjdk.org/jdk/pull/16023

From asotona at openjdk.org  Tue Oct  3 08:29:03 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 08:29:03 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:38:18 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/attribute/package-info.java line 27:
> 
>> 25: 
>> 26: /**
>> 27:  * 
Provides interfaces describing classfile attributes for the {@link java.lang.classfile} library.

> 
> Not 100% sure about the use of `h2` (here and elsewhere).

Header tags render nicely, do we have any other option?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1343707225

From asotona at openjdk.org  Tue Oct  3 08:42:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 08:42:59 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v9]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <0R0-mCGH8aqmuUN4jdIYvsEAliOdpIR31AeYRGSQCi0=.0adff479-1c7f-4a3e-9f6f-8928b7ab1eb2@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/8fd17c13..e5092a5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=07-08

  Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Tue Oct  3 08:43:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 08:43:01 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:46:53 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/instruction/CharacterRange.java line 77:
> 
>> 75:      * A flags word, indicating the kind of range.  Multiple flag bits
>> 76:      * may be set.  Valid flags include
>> 77:      * {@link java.lang.classfile.ClassFile#CRT_STATEMENT},
> 
> Maybe it would be better to organize the links in a bullet list?

Yes, fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1343724213

From mcimadamore at openjdk.org  Tue Oct  3 08:45:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 08:45:27 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 17:42:39 GMT, Maurizio Cimadamore  wrote:

>> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti 
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 770:
> 
>> 768:         PrimitiveGenerator primitiveGenerator = new PrimitiveGenerator();
>> 769:         primitiveGenerator.assembleSig(primitiveType);
>> 770:         return new Symbol.DynamicVarSymbol(names.fromString(primitiveGenerator.sb.toString()),
> 
> Why do we need a condy to generate a `Class` object for a type we know statically? E.g. will this not be resolved to .class ?

Nevermind - you need a CP entry to a CONSTANT_Class, and you are dealing with primitive types, so you need the dynamic constant in order to create one (since we do not have CP forms for primitive class literals).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343732619

From asotona at openjdk.org  Tue Oct  3 08:47:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 08:47:02 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v10]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/e5092a5f..5c834c7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From mcimadamore at openjdk.org  Tue Oct  3 08:58:00 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 08:58:00 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti 
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2929:

> 2927:             // This branch covers true unconditionality for the underlying type as well.
> 2928:             if (types.checkUnconditionallyExact(tree.expr.type, tree.pattern.type) &&
> 2929:                 !(tree.expr.type.isReference() && types.isExactPrimitiveWidening(types.unboxedType(tree.expr.type), tree.pattern.type))) {

Not super sure I get this line: if the expression type is unconditionally exact for the pattern type, shouldn't the test be always `true` ? What is the role of the extra guard after the `&&` ? Also, doesn't unconditionally exact implies that there is convertibility?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343750620

From mcimadamore at openjdk.org  Tue Oct  3 09:02:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 09:02:16 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti 
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2982:

> 2980:                     // =>
> 2981:                     // if (let tmp$123 = v; ExactnessChecks.int_float(tmp$123))
> 2982:                     JCIdent argument = make.Ident(dollar_s);

In principle you don't need a synthetic variable here... (but it's ok if you prefer to leave for uniformity)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343757201

From mcimadamore at openjdk.org  Tue Oct  3 09:08:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 09:08:05 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Tue, 3 Oct 2023 08:58:55 GMT, Maurizio Cimadamore  wrote:

>> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti 
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2982:
> 
>> 2980:                     // =>
>> 2981:                     // if (let tmp$123 = v; ExactnessChecks.int_float(tmp$123))
>> 2982:                     JCIdent argument = make.Ident(dollar_s);
> 
> In principle you don't need a synthetic variable here... (but it's ok if you prefer to leave for uniformity)

Aren't there cases here where the type of the expr is unconditional w.r.t. the type of the pattern (and so, no test is required) ? Perhaps the case I'm thinking of is dealt with one of the ifs at the beginning of this method.

I have to say I'm a bit confused by how this method is arranged. From a logical perspective I would expect first and foremost to test if the pattern type is a primitive, because that's the only case where Lower needs to do anything (right?).

Then you can have two cases: the expression has a reference type, in which case you need null check and unboxing. Or the expression has a primitive type.

In both cases you can be in a situation where the conversion is provably exact, so no need to call the exactness routine - or you can be in an inexact situation where a runtime test is required.

While I'm sure that is what happens in the above code, I think perhaps the various tests could be arranged in a way to make the above structure pop out a little more?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343767531

From mcimadamore at openjdk.org  Tue Oct  3 09:11:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 09:11:31 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti 
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3001:

> 2999:     }
> 3000: 
> 3001:     static class TypePairs {

I believe this could be a record between two TypeSymbols? Then you could have an additional constructor that takes two types and retrieves their `tsym` and call the canonical constructor (and then you can drop equals/hashcode).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343772445

From mcimadamore at openjdk.org  Tue Oct  3 09:16:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 09:16:31 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti 
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 494:

> 492:                                                                     syms.classType.tsym)));
> 493: 
> 494:             // The boolean flag `hasUnconditionalPattern` is true when either there

A it surprised that something has changed here - can you expand?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343778940

From mcimadamore at openjdk.org  Tue Oct  3 10:00:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 10:00:48 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti 
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

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

> 226:                         currentTest = trueDef;
> 227:                     } else if (currentLabelClass.isPrimitive()) {
> 228:                          if (selectorType.isInstance(Object.class)) {

As discussed offline, I believe this is wrong, and it should be replaced by `Class::equals`. That said, I think that "accidentally" you get the desired behavior here, as demonstrated by jshell:


jshell> Byte.class.isInstance(Object.class)
$6 ==> false


jshell> Object.class.isInstance(Object.class)
$8 ==> true


So, this effectively acts as a test to check if the selector type is `Object`. Of course, since `isInstance` is used, spurious stuff is picked up as well:


jshell> Class.class.isInstance(Object.class)
$7 ==> true

But this situation turns out to be non problematic, given that a primitive pattern is not applicable to a selector type Class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343840181

From mcimadamore at openjdk.org  Tue Oct  3 10:09:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 10:09:11 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v4]
In-Reply-To: 
References: 
Message-ID: 

> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
> 
> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
> 
> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
> 
> The output from javac looks as follows:
> 
> 
> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>       Arena.ofAuto().allocate(10).reinterpret(100);
>                                  ^
>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add comment in jdk.compiler's module-info

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15964/files
  - new: https://git.openjdk.org/jdk/pull/15964/files/1951b742..1751bef3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15964/head:pull/15964

PR: https://git.openjdk.org/jdk/pull/15964

From alanb at openjdk.org  Tue Oct  3 10:30:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Oct 2023 10:30:32 GMT
Subject: RFR: 8316923: Add DEF_STATIC_JNI_OnLoad for librmi
In-Reply-To: 
References: 
Message-ID: 

On Tue, 3 Oct 2023 02:19:00 GMT, Jiangli Zhou  wrote:

> Please help review this trivial change that adds missing DEF_STATIC_JNI_OnLoad for librmi.
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16020#pullrequestreview-1654871269

From asotona at openjdk.org  Tue Oct  3 12:47:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 12:47:48 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:50:56 GMT, Maurizio Cimadamore  wrote:

>> src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java line 67:
>> 
>>> 65: 
>>> 66:     /**
>>> 67:      * {@return for an {@code invokeinterface}, the {@code count} value, as defined in {@jvms 6.5}}
>> 
>> Suggestion:
>> 
>>      * {@return the {@code count} value of an {@code invokeinterface} instruction, as defined in {@jvms 6.5}}
>
> What does this return for something that is not `invokeinterface` ? Do we infer the count from the descriptor? Or do we return -1 ? This should probably be reflected in the javadoc.

Return value for other invoke instructions was inconsistent across implementations.
I've unified them to return 0 and mentioned it in the javadoc.
Thanks for pointing it out, good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344039936

From asotona at openjdk.org  Tue Oct  3 12:53:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 12:53:50 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: <7gLBfvrwDWY6W3X-ETNeiN5Glv3Ol3ykwjzqNBUVv3c=.f948789b-d2bf-4a8e-ae84-d9c1f58a8207@github.com>

On Mon, 2 Oct 2023 13:57:58 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/package-info.java line 273:
> 
>> 271:  * 

>> 272:  * More complex verification of a classfile can be achieved by explicit invocation
>> 273:  * of {@link java.lang.classfile.ClassModel#verify}.
> 
> Aren't part of verification also ran as part of generating stackmaps (unless stackmap inference is disabled) ? Should it be mentioned here?

Only fragment of verification conditions are required for stackmaps generator and it is indirectly mentioned in the sentence: "However fatal inconsistencies (like for example invalid code sequence or unresolved labels) affects internal tools and may cause exceptions later in the classfile building process."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344048341

From abimpoudis at openjdk.org  Tue Oct  3 13:28:20 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 3 Oct 2023 13:28:20 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v4]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix exhausts and equals in SwitchBootstraps

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ad6071b0..d356b36f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=02-03

  Stats: 54 lines in 3 files changed: 16 ins; 24 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Tue Oct  3 13:28:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 3 Oct 2023 13:28:29 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Tue, 3 Oct 2023 09:58:11 GMT, Maurizio Cimadamore  wrote:

>> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti 
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 228:
> 
>> 226:                         currentTest = trueDef;
>> 227:                     } else if (currentLabelClass.isPrimitive()) {
>> 228:                          if (selectorType.isInstance(Object.class)) {
> 
> As discussed offline, I believe this is wrong, and it should be replaced by `Class::equals`. That said, I think that "accidentally" you get the desired behavior here, as demonstrated by jshell:
> 
> 
> jshell> Byte.class.isInstance(Object.class)
> $6 ==> false
> 
> 
> jshell> Object.class.isInstance(Object.class)
> $8 ==> true
> 
> 
> So, this effectively acts as a test to check if the selector type is `Object`. Of course, since `isInstance` is used, spurious stuff is picked up as well:
> 
> 
> jshell> Class.class.isInstance(Object.class)
> $7 ==> true
> 
> But this situation turns out to be non problematic, given that a primitive pattern is not applicable to a selector type Class.

Fixed as well.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5052:
> 
>> 5050: 
>> 5051:         return (source.isPrimitive() && target.isPrimitive()) &&
>> 5052:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||
> 
> Does this mean that `byte` -> `char` is not exact? Aren't both integral types, thus invalidating `widening from one integral type to another` ?

Indeed it is not unconditionally exact. byte to char combines both widening and narrowing primitive conversions 

https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.4

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4154:
> 
>> 4152:     public void visitTypeTest(JCInstanceOf tree) {
>> 4153:         Type exprtype = attribExpr(tree.expr, env);
>> 4154:         if(!allowPrimitivePatterns) {
> 
> nit: space missing

Fixed!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 735:
> 
>> 733:                 }
>> 734:             }
>> 735:             if (tree.selector.type.hasTag(TypeTag.BOOLEAN)) {
> 
> I would have expected true/false to be treated more or less like enum constants when it came to exhaustiveness? E.g. boolean is similar to an enum type that only has two options (or, if you will, a sealed type with two permitted subtypes). So, IMHO the treatment for booleans should happen in the `exhausts` method - and this method should be left very simple (possibly unchanged?)

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344099605
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344095080
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344095209
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344095335

From asotona at openjdk.org  Tue Oct  3 13:43:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 13:43:47 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:54:22 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/package-info.java line 259:
> 
>> 257:  * the classfile building process.
>> 258:  * 

>> 259:  * Basic syntax control can be achieved using symbolic descriptors. For example
> 
> What does "syntax control" mean? The concept is used, but not defined, in the javadoc. (I presume we mean eg.g. turning String into `Ljava/lang/String;`)

I've reformulated and extended the paragraph a bit and added another snippet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344126800

From asotona at openjdk.org  Tue Oct  3 14:03:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 14:03:54 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <0CTJUB-_AW4VNsNoglFLvyoabSIgZEESnJCYfm029gE=.818a972c-a5c1-4654-bbcd-117c5a9107aa@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 <0CTJUB-_AW4VNsNoglFLvyoabSIgZEESnJCYfm029gE=.818a972c-a5c1-4654-bbcd-117c5a9107aa@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:03:48 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/package-info.java line 389:
> 
>> 387:  * To achieve stability of transformations in future JDK releases it is desired
>> 388:  * to set appropriate response to potential new classfile elements appearing.
>> 389:  * Transformation designed to handle all situation should be implemented strict way,
> 
> "handle all situations" - I couldn't make much sense of it. I only got it when reading the text that follows, which says "transformation selectively interested in ...". This para should be rephrased for better clarity. E.g.
> "Classfile transforms that are interested in consuming _all_ classfile elements should be implemented in a strict fashion, so that new exceptions will be issued, should a new and unknown classfile element appear ... Conversely, classfile transforms that are only interested in consuming a portion of classfile elements do not need to concern with new and unknown classfile elements ... because ... "

Thanks for the review, I've reformulated the paragraph as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344157870

From asotona at openjdk.org  Tue Oct  3 14:11:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 14:11:11 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:51:47 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> test/langtools/tools/javac/classfiles/attributes/SourceFile/NoSourceFileAttribute.java line 52:
> 
>> 50:         assertNull(
>> 51:                 ClassFile.of().parse(getClassFile(NoSourceFileAttribute.class).toPath()).findAttribute(Attributes.SOURCE_FILE).orElse(null),
>> 52:                 "ClassFile should have no SourceFile attribute when compiled without debug information.");
> 
> Not sure if replacing the camel case ClassFile in the assertion message is what you wanted here

Nice catch, fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344165330

From asotona at openjdk.org  Tue Oct  3 14:11:08 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 14:11:08 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v11]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - fixed case in the test text
 - fixing javadoc
 - Unified implementations of InvokeInstruction::count, fixed javadoc and javap CodeWriter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/5c834c7b..c1d95488

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=09-10

  Stats: 42 lines in 5 files changed: 21 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From ecaspole at openjdk.org  Tue Oct  3 14:17:37 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 3 Oct 2023 14:17:37 GMT
Subject: RFR: 8314085: Fixing scope from benchmark to thread for JMH tests
 having shared state
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma  wrote:

> In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems.
> 
> org/openjdk/bench/java/io/DataInputStreamTest.java
> org/openjdk/bench/java/lang/ArrayClone.java
> org/openjdk/bench/java/lang/StringCompareToDifferentLength.java
> org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java
> org/openjdk/bench/java/lang/StringComparisons.java
> org/openjdk/bench/java/lang/StringEquals.java
> org/openjdk/bench/java/lang/StringFormat.java
> org/openjdk/bench/java/lang/StringReplace.java
> org/openjdk/bench/java/lang/StringSubstring.java
> org/openjdk/bench/java/lang/StringTemplateFMT.java
> org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java
> org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java
> org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java
> org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java
> org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java
> org/openjdk/bench/java/security/CipherSuiteBench.java
> org/openjdk/bench/java/time/GetYearBench.java
> org/openjdk/bench/java/time/InstantBench.java
> org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java
> org/openjdk/bench/java/util/ListArgs.java
> org/openjdk/bench/java/util/LocaleDefaults.java
> org/openjdk/bench/java/util/TestAdler32.java
> org/openjdk/bench/java/util/TestCRC32.java
> org/openjdk/bench/java/util/TestCRC32C.java
> org/openjdk/bench/java/util/regex/Exponential.java
> org/openjdk/bench/java/util/regex/Primality.java
> org/openjdk/bench/java/util/regex/Trim.java
> org/openjdk/bench/javax/crypto/AESReinit.java
> org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java
> org/openjdk/bench/vm/compiler/Rotation.java
> org/openjdk/bench/vm/compiler/x86/ConvertF2I.java
> org/openjdk/bench/vm/compiler/x86/BasicRules.java
> 
> Please review and provide your feedback.
> 
> Thanks,
> Swati

Looks good, thanks for finding this problem!

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

Marked as reviewed by ecaspole (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15230#pullrequestreview-1655325889

From mcimadamore at openjdk.org  Tue Oct  3 15:00:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 15:00:36 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
 
Message-ID: <-L0VbUtNh5kdKGoUdONyiIF2RjKislGhtUcoF7ACONI=.8b7b9a17-4659-49ed-9ea9-dce41381a7b5@github.com>

On Tue, 3 Oct 2023 13:19:18 GMT, Aggelos Biboudis  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5052:
>> 
>>> 5050: 
>>> 5051:         return (source.isPrimitive() && target.isPrimitive()) &&
>>> 5052:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||
>> 
>> Does this mean that `byte` -> `char` is not exact? Aren't both integral types, thus invalidating `widening from one integral type to another` ?
>
> Indeed it is not unconditionally exact. byte to char combines both widening and narrowing primitive conversions 
> 
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.4

Ha! Of course - the problem is not the definition of "integral type" (which includes `char`), but the fact that there's no widening from `byte` to `char`. I agree that the code (and the spec changes) do the right thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344261063

From jiangli at openjdk.org  Tue Oct  3 15:39:54 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 3 Oct 2023 15:39:54 GMT
Subject: RFR: 8316923: Add DEF_STATIC_JNI_OnLoad for librmi [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please help review this trivial change that adds missing DEF_STATIC_JNI_OnLoad for librmi.
> 
> Thanks

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year as suggested by @AlanBateman.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16020/files
  - new: https://git.openjdk.org/jdk/pull/16020/files/f51209fb..bcd5dfd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16020&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16020&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16020.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16020/head:pull/16020

PR: https://git.openjdk.org/jdk/pull/16020

From jiangli at openjdk.org  Tue Oct  3 15:39:57 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 3 Oct 2023 15:39:57 GMT
Subject: RFR: 8316923: Add DEF_STATIC_JNI_OnLoad for librmi [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 3 Oct 2023 06:08:20 GMT, Alan Bateman  wrote:

> Surprised this one didn't have DEF_STATIC_JNI_OnLoad already. Change looks okay, can you update the copyright date before integrating.

Thanks for the review! Updated copyright year as you suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/16020#issuecomment-1745218266

From jiangli at openjdk.org  Tue Oct  3 15:40:48 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 3 Oct 2023 15:40:48 GMT
Subject: Integrated: 8316923: Add DEF_STATIC_JNI_OnLoad for librmi
In-Reply-To: 
References: 
Message-ID: 

On Tue, 3 Oct 2023 02:19:00 GMT, Jiangli Zhou  wrote:

> Please help review this trivial change that adds missing DEF_STATIC_JNI_OnLoad for librmi.
> 
> Thanks

This pull request has now been integrated.

Changeset: ae796a4e
Author:    Jiangli Zhou 
URL:       https://git.openjdk.org/jdk/commit/ae796a4e1000afb836c1b0a65edf39ab9d2e7ce2
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8316923: Add DEF_STATIC_JNI_OnLoad for librmi

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/16020

From duke at openjdk.org  Tue Oct  3 16:04:04 2023
From: duke at openjdk.org (Swati Sharma)
Date: Tue, 3 Oct 2023 16:04:04 GMT
Subject: Integrated: 8314085: Fixing scope from benchmark to thread for JMH
 tests having shared state
In-Reply-To: 
References: 
Message-ID: 

On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma  wrote:

> In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems.
> 
> org/openjdk/bench/java/io/DataInputStreamTest.java
> org/openjdk/bench/java/lang/ArrayClone.java
> org/openjdk/bench/java/lang/StringCompareToDifferentLength.java
> org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java
> org/openjdk/bench/java/lang/StringComparisons.java
> org/openjdk/bench/java/lang/StringEquals.java
> org/openjdk/bench/java/lang/StringFormat.java
> org/openjdk/bench/java/lang/StringReplace.java
> org/openjdk/bench/java/lang/StringSubstring.java
> org/openjdk/bench/java/lang/StringTemplateFMT.java
> org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java
> org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java
> org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java
> org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java
> org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java
> org/openjdk/bench/java/security/CipherSuiteBench.java
> org/openjdk/bench/java/time/GetYearBench.java
> org/openjdk/bench/java/time/InstantBench.java
> org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java
> org/openjdk/bench/java/util/ListArgs.java
> org/openjdk/bench/java/util/LocaleDefaults.java
> org/openjdk/bench/java/util/TestAdler32.java
> org/openjdk/bench/java/util/TestCRC32.java
> org/openjdk/bench/java/util/TestCRC32C.java
> org/openjdk/bench/java/util/regex/Exponential.java
> org/openjdk/bench/java/util/regex/Primality.java
> org/openjdk/bench/java/util/regex/Trim.java
> org/openjdk/bench/javax/crypto/AESReinit.java
> org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java
> org/openjdk/bench/vm/compiler/Rotation.java
> org/openjdk/bench/vm/compiler/x86/ConvertF2I.java
> org/openjdk/bench/vm/compiler/x86/BasicRules.java
> 
> Please review and provide your feedback.
> 
> Thanks,
> Swati

This pull request has now been integrated.

Changeset: b438cffd
Author:    Swati Sharma 
Committer: Sandhya Viswanathan 
URL:       https://git.openjdk.org/jdk/commit/b438cffdb9821fce86d215e452b41810b08b3e71
Stats:     46 lines in 38 files changed: 0 ins; 0 del; 46 mod

8314085: Fixing scope from benchmark to thread for JMH tests having shared state

Co-authored-by: Vladimir Ivanov 
Reviewed-by: sviswanathan, ecaspole

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

PR: https://git.openjdk.org/jdk/pull/15230

From jlu at openjdk.org  Tue Oct  3 16:25:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Oct 2023 16:25:32 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v6]
In-Reply-To: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
References: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
Message-ID: 

> Please review this PR which removes the i18n related testing base classes `IntlTest` and `CollatorTest` and converts all the tests that use them,
> 
> IntlTest and CollatorTest are testing classes which are extended by tests in `text/`, `util/Locale`, `util/TimeZone`, and `util/Calendar`. The abstract testing classes are quite dated and have caused issues such as: variation between OS, hiding stack trace, and causing tests to spuriously pass.
> 
> This change mainly automates a low level conversion of all the tests (75) using the frameworks; all tests were converted to use JUnit instead. (With the exception of `DateFormatRoundTripTest` due to the nature of the test).
> 
> The main changes can be viewed in the following commits
> 
> scripted changes - [c0ece01 ](https://github.com/openjdk/jdk/commit/c0ece01e91479a020d5c6dce937dc827472b763b)
> - Converts the IntlTest methods logln, log, err, and errln
> - Adds the JUnit Test annotation to tests that should be ran
> - Adjusts the Jtreg tags accordingly
> - Remove the main method
> - Insert initAll() methods for tests that previously adjusted the JVM default Locale/TimeZone in the main method
> 
> manual changes - [9a54910](https://github.com/openjdk/jdk/commit/9a5491065a94a4dc7a05194f3b8330efba8077b7)
> - Some tests that had extensive logic in the main method or did not follow the general IntlTest format had to be manually adjusted
> - Also clarified some tests that had optional argument setup in the main method (now removed)
> 
> removal of IntlTest and CollatorTest - [8ee9f9c](https://github.com/openjdk/jdk/commit/8ee9f9c79f79210ee6244186970d87a1cac05556) [f90266f](https://github.com/openjdk/jdk/pull/15954/commits/f90266f4f019c031c5f985dd658f62a02cc8b422) [3c67679](https://github.com/openjdk/jdk/pull/15954/commits/3c676794dd0c703db066a346c36e213d113d9acc)
> - Removes IntlTest in both the testlib and under TimeZone/
> - Replaces CollatorTest with CollatorTestUtils
> 
> Tiers 1-3 clean

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  typo in import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15954/files
  - new: https://git.openjdk.org/jdk/pull/15954/files/47532e8a..d20b085c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15954/head:pull/15954

PR: https://git.openjdk.org/jdk/pull/15954

From jlu at openjdk.org  Tue Oct  3 16:41:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Oct 2023 16:41:49 GMT
Subject: Integrated: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest
In-Reply-To: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
References: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
Message-ID: 

On Thu, 28 Sep 2023 01:02:46 GMT, Justin Lu  wrote:

> Please review this PR which removes the i18n related testing base classes `IntlTest` and `CollatorTest` and converts all the tests that use them,
> 
> IntlTest and CollatorTest are testing classes which are extended by tests in `text/`, `util/Locale`, `util/TimeZone`, and `util/Calendar`. The abstract testing classes are quite dated and have caused issues such as: variation between OS, hiding stack trace, and causing tests to spuriously pass.
> 
> This change mainly automates a low level conversion of all the tests (75) using the frameworks; all tests were converted to use JUnit instead. (With the exception of `DateFormatRoundTripTest` due to the nature of the test).
> 
> The main changes can be viewed in the following commits
> 
> scripted changes - [c0ece01 ](https://github.com/openjdk/jdk/commit/c0ece01e91479a020d5c6dce937dc827472b763b)
> - Converts the IntlTest methods logln, log, err, and errln
> - Adds the JUnit Test annotation to tests that should be ran
> - Adjusts the Jtreg tags accordingly
> - Remove the main method
> - Insert initAll() methods for tests that previously adjusted the JVM default Locale/TimeZone in the main method
> 
> manual changes - [9a54910](https://github.com/openjdk/jdk/commit/9a5491065a94a4dc7a05194f3b8330efba8077b7)
> - Some tests that had extensive logic in the main method or did not follow the general IntlTest format had to be manually adjusted
> - Also clarified some tests that had optional argument setup in the main method (now removed)
> 
> removal of IntlTest and CollatorTest - [8ee9f9c](https://github.com/openjdk/jdk/commit/8ee9f9c79f79210ee6244186970d87a1cac05556) [f90266f](https://github.com/openjdk/jdk/pull/15954/commits/f90266f4f019c031c5f985dd658f62a02cc8b422) [3c67679](https://github.com/openjdk/jdk/pull/15954/commits/3c676794dd0c703db066a346c36e213d113d9acc)
> - Removes IntlTest in both the testlib and under TimeZone/
> - Replaces CollatorTest with CollatorTestUtils
> 
> Tiers 1-3 clean

This pull request has now been integrated.

Changeset: b859da9c
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/b859da9c548fbd1463b336059d1c55312c7b7ba4
Stats:     4465 lines in 79 files changed: 922 ins; 1081 del; 2462 mod

8316696: Remove the testing base classes: IntlTest and CollatorTest

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/15954

From joehw at openjdk.org  Tue Oct  3 18:23:36 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 3 Oct 2023 18:23:36 GMT
Subject: RFR: 8317265: ListFormat::format specification could be made
 clearer regarding handling IllegalArgumentException.
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 16:59:00 GMT, Naoto Sato  wrote:

> A simple clarification of the conditions for throwing an IAE.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16013#pullrequestreview-1655850720

From liach at openjdk.org  Tue Oct  3 18:32:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Oct 2023 18:32:44 GMT
Subject: RFR: 8180892: Correct handling of annotations on parameters [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 27 Apr 2023 23:42:54 GMT, Joe Darcy  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix assuming match without MethodParameters for type annotations, move implementation related to getAnnotatedParameterTypes to around it
>
> @liach , thank you for working on this fix. I've given the changes an initial skim, but will need to do a more thorough review before approving or offering suggestions for changes. My top priority for the next few weeks will be JDK 21 CSRs so it may take a while for me to circle back to this PR.

@jddarcy Joe, can you take a look at this patch where annotation handling on parameters now uses available `MethodParameters` attribute to match from explicit formal parameter indices to implicit formal parameter indices?

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

PR Comment: https://git.openjdk.org/jdk/pull/13664#issuecomment-1745507837

From naoto at openjdk.org  Tue Oct  3 18:36:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Oct 2023 18:36:05 GMT
Subject: Integrated: 8317265: ListFormat::format specification could be made
 clearer regarding handling IllegalArgumentException.
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 16:59:00 GMT, Naoto Sato  wrote:

> A simple clarification of the conditions for throwing an IAE.

This pull request has now been integrated.

Changeset: 1809b8cd
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/1809b8cdd6f27fd2f19072a874f5020ca717ad11
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8317265: ListFormat::format specification could be made clearer regarding handling IllegalArgumentException.

Reviewed-by: joehw

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

PR: https://git.openjdk.org/jdk/pull/16013

From duke at openjdk.org  Tue Oct  3 18:59:23 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 3 Oct 2023 18:59:23 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v11]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: <2l3nPeHsaRxgmPSihVa2engMW0eMBBqqAK4HBJbfV6k=.5733dff5-ac59-4c55-8b26-32eff1f0fefe@github.com>

On Tue, 3 Oct 2023 14:11:08 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fixed case in the test text
>  - fixing javadoc
>  - Unified implementations of InvokeInstruction::count, fixed javadoc and javap CodeWriter

src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java line 299:

> 297:         }
> 298:         maxStringLength = currentMaxStringLength;
> 299:         // The ClassFile's access_flags field is just after the last constant pool entry.

This?has nothing to?do?with the?`ClassFile`?API
Suggestion:

        // The Classfile's access_flags field is just after the last constant pool entry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344576036

From sviswanathan at openjdk.org  Tue Oct  3 23:16:50 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 3 Oct 2023 23:16:50 GMT
Subject: RFR: 8314544: Matrix multiple benchmark using Vector API
In-Reply-To: <8BXkyGnNgMS6iktaExy65qSluRvYoS1ww-1ZS6ekMxY=.ffab5a85-17da-41b6-8056-ae7bb721bd2a@github.com>
References: 
 <8BXkyGnNgMS6iktaExy65qSluRvYoS1ww-1ZS6ekMxY=.ffab5a85-17da-41b6-8056-ae7bb721bd2a@github.com>
Message-ID: 

On Mon, 21 Aug 2023 03:50:32 GMT, Martin Stypinski  wrote:

>> Added a bunch of different implementations for Vector API Matrix Multiplications:
>> 
>> - Baseline
>> - Blocked (Cache Local)
>> - FMA
>> - Vector API Simple Implementation
>> - Vector API Blocked Implementation
>> 
>> Commit was discussed with @PaulSandoz
>
> Changed according to comments.

@Styp Please correct the title in the PR. There is title mismatch between PR and JBS.
PR title: Matrix multiple benchmark using Vector API
"multiple" vs "multiply"

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

PR Comment: https://git.openjdk.org/jdk/pull/15338#issuecomment-1745869944

From asotona at openjdk.org  Wed Oct  4 05:35:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Oct 2023 05:35:49 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v12]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/c1d95488..859afe81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Wed Oct  4 05:35:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Oct 2023 05:35:52 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v11]
In-Reply-To: <2l3nPeHsaRxgmPSihVa2engMW0eMBBqqAK4HBJbfV6k=.5733dff5-ac59-4c55-8b26-32eff1f0fefe@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 <2l3nPeHsaRxgmPSihVa2engMW0eMBBqqAK4HBJbfV6k=.5733dff5-ac59-4c55-8b26-32eff1f0fefe@github.com>
Message-ID: <21Ioc75aRIQsnmIWOa4YoMTofa0rqdiEH80vjhutsOo=.0f51e3b3-fac3-4a9e-9827-53f9566a9b82@github.com>

On Tue, 3 Oct 2023 18:55:36 GMT, ExE Boss  wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - fixed case in the test text
>>  - fixing javadoc
>>  - Unified implementations of InvokeInstruction::count, fixed javadoc and javap CodeWriter
>
> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java line 299:
> 
>> 297:         }
>> 298:         maxStringLength = currentMaxStringLength;
>> 299:         // The ClassFile's access_flags field is just after the last constant pool entry.
> 
> This?has nothing to?do?with the?`ClassFile`?API
> Suggestion:
> 
>         // The Classfile's access_flags field is just after the last constant pool entry.

Thanks for catching it, the refactoring was a bit more aggressive than expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1345214426

From asotona at openjdk.org  Wed Oct  4 09:09:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Oct 2023 09:09:34 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v13]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <0e7ss_3aiu_Su7Aam9NQVNpY4sk32g6_4vP64PqmzvM=.91abde8c-0e66-46b4-86e6-77ef95b6a55d@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 336 commits:

 - Merge branch 'master' into JDK-8308753-preview
 - Update src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - fixed case in the test text
 - fixing javadoc
 - Unified implementations of InvokeInstruction::count, fixed javadoc and javap CodeWriter
 - Update src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - fixing javadoc
 - fixing javadoc
 - fixing javadoc
 - Apply suggestions from code review
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - ... and 326 more: https://git.openjdk.org/jdk/compare/d4c904d8...ef2305d8

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=12
  Stats: 29011 lines in 759 files changed: 13016 ins; 12505 del; 3490 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From abimpoudis at openjdk.org  Wed Oct  4 09:26:22 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 09:26:22 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v5]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary disambiguation in TransPatterns and simplify Lower.visitTypeTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/d356b36f..f036fdbc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=03-04

  Stats: 21 lines in 3 files changed: 0 ins; 15 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From asotona at openjdk.org  Wed Oct  4 09:30:16 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Oct 2023 09:30:16 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v14]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed hotspot test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/ef2305d8..a6a73b37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=12-13

  Stats: 13 lines in 1 file changed: 1 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From mcimadamore at openjdk.org  Wed Oct  4 09:39:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Oct 2023 09:39:50 GMT
Subject: Integrated: 8316971: Add Lint warning for restricted method calls
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Sep 2023 13:13:31 GMT, Maurizio Cimadamore  wrote:

> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
> 
> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
> 
> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
> 
> The output from javac looks as follows:
> 
> 
> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>       Arena.ofAuto().allocate(10).reinterpret(100);
>                                  ^
>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

This pull request has now been integrated.

Changeset: 0d4de8a7
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/0d4de8a71f063e44618f43ddd862a91aed647f48
Stats:     119 lines in 15 files changed: 115 ins; 0 del; 4 mod

8316971: Add Lint warning for restricted method calls

Reviewed-by: ihse, vromero

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

PR: https://git.openjdk.org/jdk/pull/15964

From abimpoudis at openjdk.org  Wed Oct  4 10:02:39 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 10:02:39 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v6]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Rename exactness methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/f036fdbc..1d88baaf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=04-05

  Stats: 76 lines in 3 files changed: 0 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Wed Oct  4 10:02:44 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 10:02:44 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Tue, 3 Oct 2023 09:13:30 GMT, Maurizio Cimadamore  wrote:

>> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti 
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 494:
> 
>> 492:                                                                     syms.classType.tsym)));
>> 493: 
>> 494:             // The boolean flag `hasUnconditionalPattern` is true when either there
> 
> A it surprised that something has changed here - can you expand?

Indeed that was not needed anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1345531726

From abimpoudis at openjdk.org  Wed Oct  4 10:13:40 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 10:13:40 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v7]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Simplify TypePairs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/1d88baaf..ef98c040

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=05-06

  Stats: 49 lines in 2 files changed: 0 ins; 44 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Wed Oct  4 10:13:43 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 10:13:43 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: <8MevNyryZdtgfndhK_ASX5NGLaXesVGfJ89iSLYJyzg=.cd11e37d-bba0-4d02-a044-addb706f6852@github.com>

On Tue, 3 Oct 2023 09:08:31 GMT, Maurizio Cimadamore  wrote:

>> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti 
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3001:
> 
>> 2999:     }
>> 3000: 
>> 3001:     static class TypePairs {
> 
> I believe this could be a record between two TypeSymbols? Then you could have an additional constructor that takes two types and retrieves their `tsym` and call the canonical constructor (and then you can drop equals/hashcode).

Done and simplified https://github.com/openjdk/jdk/pull/15638/commits/ef98c040c909981077936c6ff4280b6da04b8c24. Do you think we can simplify further (or benefit at all) by also eliminating duplication between SwitchBootstrap and Lower?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1345545796

From shaojin.wensj at alibaba-inc.com  Wed Oct  4 14:22:27 2023
From: shaojin.wensj at alibaba-inc.com (=?UTF-8?B?5rip57uN6ZSmKOmrmOmTgSk=?=)
Date: Wed, 04 Oct 2023 22:22:27 +0800
Subject: =?UTF-8?B?SVNPIFN0YXJuZGFyZCBEYXRlIEZvcm1hdCBpbXBsZW1lbnRhdGlvbiBjb25zaXN0ZW5jeSBv?=
 =?UTF-8?B?biBEYXRlVGltZUZvcm1hdHRlciBhbmQgU3RyaW5nLmZvcm1hdA==?=
Message-ID: <875b3104-40f7-48b9-b003-b19ac5e2ce09.shaojin.wensj@alibaba-inc.com>

j.t.DateTimeFormatter defines ISO_LOCAL_DATE, j.u.Formatter.DateTime also defines ISO_STANDARD_DATE ("%tF"), and now their behavior is different outside the range of [0,9999], We run the following code and we can see their different behaviors:
```java
DateTimeFormatter formatter = DateTimeFormatter.ISO_LOCAL_DATE;
int[] years = {-99999, -9999, -999, -99, -9, 0, 9, 99, 999, 1999, 2999, 9999, 99999};
for (int year : years) {
 LocalDate localDate = LocalDate.of(year, 1, 1);
 System.out.println(formatter.format(localDate) + "\t\t->\t\t" + "%tF".formatted(localDate));
}
```
* output
```
-99999-01-01 -> 100000-01-01
-9999-01-01 -> 10000-01-01
-0999-01-01 -> 1000-01-01
-0099-01-01 -> 0100-01-01
-0009-01-01 -> 0010-01-01
0000-01-01 -> 0001-01-01
0009-01-01 -> 0009-01-01
0099-01-01 -> 0099-01-01
0999-01-01 -> 0999-01-01
1999-01-01 -> 1999-01-01
2999-01-01 -> 2999-01-01
9999-01-01 -> 9999-01-01
+99999-01-01 -> 99999-01-01
```
Should we keep it consistent?
- wenshao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From naoto at openjdk.org  Wed Oct  4 17:26:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 4 Oct 2023 17:26:34 GMT
Subject: RFR: 8317443: StackOverflowError on calling ListFormat::getInstance()
 for Norwegian locales
Message-ID: 

Please review the fix to the subject issue. This was found during upgrading CLDR to v44, in which some list patterns are missing (thus to be inherited from parents) in Norwegian locales which could end up with infinite parent lookup. Avoiding the recursive call and changing it to a plain loop fixes the issue.
Not related to this issue, the test case has been corrected to work with any locale. Currently, it assumes English.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/16042/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16042&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317443
  Stats: 15 lines in 2 files changed: 2 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16042/head:pull/16042

PR: https://git.openjdk.org/jdk/pull/16042

From naoto at openjdk.org  Wed Oct  4 18:11:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 4 Oct 2023 18:11:28 GMT
Subject: RFR: 8267509: Improve IllegalAccessException message to include
 the cause of the exception [v3]
In-Reply-To: <_dK6ECQnlvrIg7rV9NGI6HK4p8fr5L_AQsyDSUJw0G8=.9a08ea49-ef5c-4355-a892-03b083180b58@github.com>
References: <8Ka-IY9mMbtFNWGAr5h-etSp-1WFkeaC4kJP_zO_KGg=.c9aaf508-c6c1-4b65-bc07-2c889cc4c578@github.com>
 <_dK6ECQnlvrIg7rV9NGI6HK4p8fr5L_AQsyDSUJw0G8=.9a08ea49-ef5c-4355-a892-03b083180b58@github.com>
Message-ID: <_03AcVAUAyOwd_dGRlcTPfvBD6eapUpqEMeRfp3bsI8=.b7f62665-1c19-4fdc-a9d0-93b46188f262@github.com>

On Wed, 13 Sep 2023 17:52:22 GMT, Mandy Chung  wrote:

>> This PR improves IllegalAccessException message thrown by `Lookup::findXXX` APIs if the method's variable arity modifier bit is set and `asVarargsCollector` fails.  It will increase the exception message thrown by asVarargsCollector`.
>> 
>> The exception message looks like this:
>> 
>> java.lang.IllegalAccessException: cannot make variable arity: MyClass.m(Object[],int)void/invokeStatic does not have a trailing array parameter
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revised message

Would it be helpful if we call `IllegalAccessException.initCause(IllegalArgumentException)` before throwing it?

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

PR Comment: https://git.openjdk.org/jdk/pull/15698#issuecomment-1747399304

From naoto at openjdk.org  Wed Oct  4 18:32:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 4 Oct 2023 18:32:22 GMT
Subject: RFR: 8267509: Improve IllegalAccessException message to include
 the cause of the exception [v3]
In-Reply-To: <_dK6ECQnlvrIg7rV9NGI6HK4p8fr5L_AQsyDSUJw0G8=.9a08ea49-ef5c-4355-a892-03b083180b58@github.com>
References: <8Ka-IY9mMbtFNWGAr5h-etSp-1WFkeaC4kJP_zO_KGg=.c9aaf508-c6c1-4b65-bc07-2c889cc4c578@github.com>
 <_dK6ECQnlvrIg7rV9NGI6HK4p8fr5L_AQsyDSUJw0G8=.9a08ea49-ef5c-4355-a892-03b083180b58@github.com>
Message-ID: 

On Wed, 13 Sep 2023 17:52:22 GMT, Mandy Chung  wrote:

>> This PR improves IllegalAccessException message thrown by `Lookup::findXXX` APIs if the method's variable arity modifier bit is set and `asVarargsCollector` fails.  It will include the exception message thrown by asVarargsCollector`.
>> 
>> The exception message looks like this:
>> 
>> java.lang.IllegalAccessException: cannot make variable arity: MyClass.m(Object[],int)void/invokeStatic does not have a trailing array parameter
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revised message

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15698#pullrequestreview-1658248304

From mchung at openjdk.org  Wed Oct  4 18:32:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Oct 2023 18:32:22 GMT
Subject: RFR: 8267509: Improve IllegalAccessException message to include
 the cause of the exception [v3]
In-Reply-To: <_dK6ECQnlvrIg7rV9NGI6HK4p8fr5L_AQsyDSUJw0G8=.9a08ea49-ef5c-4355-a892-03b083180b58@github.com>
References: <8Ka-IY9mMbtFNWGAr5h-etSp-1WFkeaC4kJP_zO_KGg=.c9aaf508-c6c1-4b65-bc07-2c889cc4c578@github.com>
 <_dK6ECQnlvrIg7rV9NGI6HK4p8fr5L_AQsyDSUJw0G8=.9a08ea49-ef5c-4355-a892-03b083180b58@github.com>
Message-ID: <436WnXy22h8A2w-Vtq_O0woNrRqmlpuUs2RpB8C3t0I=.ad40791c-8c78-41a8-9895-fbe2ac16e3f5@github.com>

On Wed, 13 Sep 2023 17:52:22 GMT, Mandy Chung  wrote:

>> This PR improves IllegalAccessException message thrown by `Lookup::findXXX` APIs if the method's variable arity modifier bit is set and `asVarargsCollector` fails.  It will include the exception message thrown by asVarargsCollector`.
>> 
>> The exception message looks like this:
>> 
>> java.lang.IllegalAccessException: cannot make variable arity: MyClass.m(Object[],int)void/invokeStatic does not have a trailing array parameter
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revised message

It's a user error. The exception message makes it clear for the users what's wrong with the requested method.   The cause's stacktrace is less relevant to them.

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

PR Comment: https://git.openjdk.org/jdk/pull/15698#issuecomment-1747425360

From mchung at openjdk.org  Wed Oct  4 18:42:21 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Oct 2023 18:42:21 GMT
Subject: Integrated: 8267509: Improve IllegalAccessException message to include
 the cause of the exception
In-Reply-To: <8Ka-IY9mMbtFNWGAr5h-etSp-1WFkeaC4kJP_zO_KGg=.c9aaf508-c6c1-4b65-bc07-2c889cc4c578@github.com>
References: <8Ka-IY9mMbtFNWGAr5h-etSp-1WFkeaC4kJP_zO_KGg=.c9aaf508-c6c1-4b65-bc07-2c889cc4c578@github.com>
Message-ID: 

On Wed, 13 Sep 2023 01:12:52 GMT, Mandy Chung  wrote:

> This PR improves IllegalAccessException message thrown by `Lookup::findXXX` APIs if the method's variable arity modifier bit is set and `asVarargsCollector` fails.  It will include the exception message thrown by asVarargsCollector`.
> 
> The exception message looks like this:
> 
> java.lang.IllegalAccessException: cannot make variable arity: MyClass.m(Object[],int)void/invokeStatic does not have a trailing array parameter

This pull request has now been integrated.

Changeset: 36314a90
Author:    Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/36314a90c15e2ab2a9b32c2e471655c1b07d452c
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8267509: Improve IllegalAccessException message to include the cause of the exception

Reviewed-by: liach, naoto

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

PR: https://git.openjdk.org/jdk/pull/15698

From bpb at openjdk.org  Wed Oct  4 20:35:25 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Oct 2023 20:35:25 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v7]
In-Reply-To: 
References: 
Message-ID: <26zgN9543IcbQEum-nEsgfSv4v8412UkkJ412GszuXw=.44fa0b44-fc17-40d0-99a6-87d6d8be58a1@github.com>

> In the Windows implementation of java.io.File.getCanonicalPath, strip any long path or UNC prefix before canonicalizing the remainder of the pathname.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8287843: Remove unused constant and method from WindowsPrefixes test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15603/files
  - new: https://git.openjdk.org/jdk/pull/15603/files/d05eba05..a43f7276

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=05-06

  Stats: 18 lines in 1 file changed: 5 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15603.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15603/head:pull/15603

PR: https://git.openjdk.org/jdk/pull/15603

From mchung at openjdk.org  Wed Oct  4 21:43:26 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Oct 2023 21:43:26 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v14]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed hotspot test

Marked as reviewed by mchung (Reviewer).

I reviewed java.base, jlink, jdeps, jartool source and test changes except the Class-File API and implementation (i.e. `java/lang/classfile/**` and `jdk/internal/classfile/**`).

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

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1658532577
PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1747681315

From joehw at openjdk.org  Wed Oct  4 21:53:09 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 4 Oct 2023 21:53:09 GMT
Subject: RFR: 8317443: StackOverflowError on calling
 ListFormat::getInstance() for Norwegian locales
In-Reply-To: 
References: 
Message-ID: <413nEWfXzYt1xL-8FlmHmEnUKTrWXkdRda5EaAp6Yog=.d51401bd-16ab-453e-8090-a48b9e2b8386@github.com>

On Wed, 4 Oct 2023 17:17:57 GMT, Naoto Sato  wrote:

> Please review the fix to the subject issue. This was found during upgrading CLDR to v44, in which some list patterns are missing (thus to be inherited from parents) in Norwegian locales which could end up with infinite parent lookup. Avoiding the recursive call and changing it to a plain loop fixes the issue.
> Not related to this issue, the test case has been corrected to work with any locale. Currently, it assumes English.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16042#pullrequestreview-1658542105

From vromero at openjdk.org  Wed Oct  4 22:18:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Oct 2023 22:18:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v14]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed hotspot test

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1658577826

From joehw at openjdk.org  Wed Oct  4 23:05:11 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 4 Oct 2023 23:05:11 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method
Message-ID: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>

Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.

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

Commit messages:
 - 8316996: Catalog API Enhancement: add a factory method

Changes: https://git.openjdk.org/jdk/pull/16045/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316996
  Stats: 219 lines in 6 files changed: 210 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16045/head:pull/16045

PR: https://git.openjdk.org/jdk/pull/16045

From duke at openjdk.org  Wed Oct  4 23:09:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 4 Oct 2023 23:09:11 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 8 Sep 2023 14:50:15 GMT, Claes Redestad  wrote:

> Seems like a step in the right direction w.r.t. code duplication. There's still a lot going on in this PR so it'll take some time to digest. Is there some way to split this into a series of enhancements for easier review? The `jla.newStringLatin1NoRepl` additions could be split out and done first - along with evidence that it helps in other places like UUID and HexFormat.

Thank you for taking the time to help with the review. I will split these changes into multiple PRs to make the changes in each PR smaller and easier to review. I have created a new PR #16006

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

PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1747766544

From duke at openjdk.org  Wed Oct  4 23:11:27 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 4 Oct 2023 23:11:27 GMT
Subject: RFR: 8315585: Optimization for decimal to string
Message-ID: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>

I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.

this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster, Here are the numbers run on a MacBook M1 Pro:


-Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
-BigDecimals.testHugeToEngineeringString   avgt   15   228.102 ? 12.568  ns/op
-BigDecimals.testLargeToEngineeringString  avgt   15    53.814 ?  0.180  ns/op
-BigDecimals.testSmallToEngineeringString  avgt   15    17.521 ?  0.521  ns/op
-BigDecimals.testToEngineeringString       avgt   15  1814.858 ? 64.432  ns/op

+Benchmark                                 Mode  Cnt     Score    Error  Units ()
+BigDecimals.testHugeToEngineeringString   avgt   15   209.579 ?  5.037  ns/op (+8.84)
+BigDecimals.testLargeToEngineeringString  avgt   15    29.617 ?  0.557  ns/op (+81.70)
+BigDecimals.testSmallToEngineeringString  avgt   15    11.230 ?  0.075  ns/op (+56.02)
+BigDecimals.testToEngineeringString       avgt   15  1732.913 ? 33.629  ns/op (+4.73)


Please review and don't hesitate to critique my approach and patch.

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

Commit messages:
 - optimize BigDecimal.toString

Changes: https://git.openjdk.org/jdk/pull/16006/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315585
  Stats: 198 lines in 6 files changed: 121 ins; 59 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From duke at openjdk.org  Wed Oct  4 23:11:28 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 4 Oct 2023 23:11:28 GMT
Subject: RFR: 8315585: Optimization for decimal to string
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: 

On Mon, 2 Oct 2023 05:40:03 GMT, ???  wrote:

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster, Here are the numbers run on a MacBook M1 Pro:
> 
> 
> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
> -BigDecimals.testHugeToEngineeringString   avgt   15   228.102 ? 12.568  ns/op
> -BigDecimals.testLargeToEngineeringString  avgt   15    53.814 ?  0.180  ns/op
> -BigDecimals.testSmallToEngineeringString  avgt   15    17.521 ?  0.521  ns/op
> -BigDecimals.testToEngineeringString       avgt   15  1814.858 ? 64.432  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units ()
> +BigDecimals.testHugeToEngineeringString   avgt   15   209.579 ?  5.037  ns/op (+8.84)
> +BigDecimals.testLargeToEngineeringString  avgt   15    29.617 ?  0.557  ns/op (+81.70)
> +BigDecimals.testSmallToEngineeringString  avgt   15    11.230 ?  0.075  ns/op (+56.02)
> +BigDecimals.testToEngineeringString       avgt   15  1732.913 ? 33.629  ns/op (+4.73)
> 
> 
> Please review and don't hesitate to critique my approach and patch.

@jddarcy, could you please review my code? Thank you!

@cl4es could you please review my code? Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1742433534
PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1747767234

From duke at openjdk.org  Thu Oct  5 00:44:19 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 5 Oct 2023 00:44:19 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v13]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 <9PZeY6qD_y8-v4wSS5UgohDHFz8kaol2pMdg8gR9Nbo=.4145a0f3-fa09-456c-804c-5f82c8d1a50e@github.com>
 
Message-ID: 

On Thu, 28 Sep 2023 15:01:25 GMT, Raffaello Giulietti  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor according to rgiulietti's suggestion and add testcases
>
> Meaningful external reviews take a _lot_ of engineering time on such a popular platform as the JDK.
> They make sense only on somehow stable code, otherwise they are a waste of human resources.
> 
> So sure, take your time to stabilize your code, make your tests, but please refrain from keep on changing too much once you publish a PR. If reviewers have to face continuous changes, they might become uninterested in reviewing.

@rgiulietti I have no plans to make changes, Can you help me continue the review? Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1747854315

From asotona at openjdk.org  Thu Oct  5 06:37:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 5 Oct 2023 06:37:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v14]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed hotspot test

Thank you for all the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1748174064

From abimpoudis at openjdk.org  Thu Oct  5 08:21:04 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 08:21:04 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Tue, 3 Oct 2023 08:54:57 GMT, Maurizio Cimadamore  wrote:

>> Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti 
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2929:
> 
>> 2927:             // This branch covers true unconditionality for the underlying type as well.
>> 2928:             if (types.checkUnconditionallyExact(tree.expr.type, tree.pattern.type) &&
>> 2929:                 !(tree.expr.type.isReference() && types.isExactPrimitiveWidening(types.unboxedType(tree.expr.type), tree.pattern.type))) {
> 
> Not super sure I get this line: if the expression type is unconditionally exact for the pattern type, shouldn't the test be always `true` ? What is the role of the extra guard after the `&&` ? Also, doesn't unconditionally exact implies that there is convertibility?

Agree to all. Convertibility was covered.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1346991986

From abimpoudis at openjdk.org  Thu Oct  5 08:20:58 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 08:20:58 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Declutter Lower.visitTypeTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ef98c040..ceee1e4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=06-07

  Stats: 91 lines in 1 file changed: 22 ins; 43 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Thu Oct  5 08:21:07 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 08:21:07 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
 
Message-ID: <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>

On Tue, 3 Oct 2023 09:05:17 GMT, Maurizio Cimadamore  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2982:
>> 
>>> 2980:                     // =>
>>> 2981:                     // if (let tmp$123 = v; ExactnessChecks.int_float(tmp$123))
>>> 2982:                     JCIdent argument = make.Ident(dollar_s);
>> 
>> In principle you don't need a synthetic variable here... (but it's ok if you prefer to leave for uniformity)
>
> Aren't there cases here where the type of the expr is unconditional w.r.t. the type of the pattern (and so, no test is required) ? Perhaps the case I'm thinking of is dealt with one of the ifs at the beginning of this method.
> 
> I have to say I'm a bit confused by how this method is arranged. From a logical perspective I would expect first and foremost to test if the pattern type is a primitive, because that's the only case where Lower needs to do anything (right?).
> 
> Then you can have two cases: the expression has a reference type, in which case you need null check and unboxing. Or the expression has a primitive type.
> 
> In both cases you can be in a situation where the conversion is provably exact, so no need to call the exactness routine - or you can be in an inexact situation where a runtime test is required.
> 
> While I'm sure that is what happens in the above code, I think perhaps the various tests could be arranged in a way to make the above structure pop out a little more?

Refactoring attempt No. 1 complete. I need to recheck the completeness of `checkUnconditionallyExact`. In a following commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1346993616

From rgiulietti at openjdk.org  Thu Oct  5 09:35:34 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Oct 2023 09:35:34 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods in
 j.l.Integer and j.l.Long
Message-ID: 

See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.

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

Commit messages:
 - 8317515: Unify the code of the parse*() families of methods in j.l.Integer and j.l.Long

Changes: https://git.openjdk.org/jdk/pull/16050/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16050&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317515
  Stats: 458 lines in 2 files changed: 93 ins; 160 del; 205 mod
  Patch: https://git.openjdk.org/jdk/pull/16050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16050/head:pull/16050

PR: https://git.openjdk.org/jdk/pull/16050

From mcimadamore at openjdk.org  Thu Oct  5 10:02:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Oct 2023 10:02:37 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Thu, 5 Oct 2023 08:20:58 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declutter Lower.visitTypeTest

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 35:

> 33:  * @since 22
> 34:  */
> 35: final public class ExactnessMethods {

I think it should be `public final` (order of modifier)

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

> 556:     }
> 557: 
> 558:     record TypePairs(Class from, Class to) {

Nice!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347148799
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347149579

From mcimadamore at openjdk.org  Thu Oct  5 10:10:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Oct 2023 10:10:22 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Thu, 5 Oct 2023 08:20:58 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declutter Lower.visitTypeTest

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2938:

> 2936:                 }
> 2937:             }
> 2938:             else if (tree.expr.type.isReference()) {

Much better logic!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347162809

From jkern at openjdk.org  Thu Oct  5 10:12:53 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 5 Oct 2023 10:12:53 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5
Message-ID: 

We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.

test TreeTest.test5(): failure
java.lang.AssertionError: expected direct children expected [2] but found [3]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:907)
        at TreeTest.test5(TreeTest.java:447)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1570)

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

Commit messages:
 - JDK-8315026

Changes: https://git.openjdk.org/jdk/pull/16051/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16051&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315026
  Stats: 111 lines in 2 files changed: 108 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16051.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16051/head:pull/16051

PR: https://git.openjdk.org/jdk/pull/16051

From mcimadamore at openjdk.org  Thu Oct  5 10:15:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Oct 2023 10:15:23 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Thu, 5 Oct 2023 08:20:58 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declutter Lower.visitTypeTest

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

> 228:                          if (selectorType.equals(Object.class)) {
> 229:                             currentTest = INSTANCEOF_CHECK;
> 230:                             if (currentLabelClass.isAssignableFrom(byte.class)) { testLabel = Byte.class; }

I assume here you want to box the primitive, right? If that's the case, consider using the JDK class `sun.invoke.util.Wrapper`, which has a factory `forBasicType` that takes a class. From there you can get the boxed type easily, in a single line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347171504

From rgiulietti at openjdk.org  Thu Oct  5 10:31:31 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Oct 2023 10:31:31 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
Message-ID: 

> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Avoid localized integers in radix-out-of-range exception messages.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16050/files
  - new: https://git.openjdk.org/jdk/pull/16050/files/3b743686..bb4cc608

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16050&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16050&range=00-01

  Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16050/head:pull/16050

PR: https://git.openjdk.org/jdk/pull/16050

From abimpoudis at openjdk.org  Thu Oct  5 11:03:47 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 11:03:47 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v9]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Use sun.invoke.util.Wrapper in SwitchBootstraps

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ceee1e4c..c8b860d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=07-08

  Stats: 10 lines in 3 files changed: 1 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Thu Oct  5 11:23:15 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 11:23:15 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
 
Message-ID: <3_dYhTYH2wTojdNSbjB9VWmH6SZtO-fC9IFXAVQD3v4=.72a9449c-1be4-4ffa-9b9a-132219d52b24@github.com>

On Thu, 5 Oct 2023 09:58:52 GMT, Maurizio Cimadamore  wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Declutter Lower.visitTypeTest
>
> src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 35:
> 
>> 33:  * @since 22
>> 34:  */
>> 35: final public class ExactnessMethods {
> 
> I think it should be `public final` (order of modifier)

Done

> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 230:
> 
>> 228:                          if (selectorType.equals(Object.class)) {
>> 229:                             currentTest = INSTANCEOF_CHECK;
>> 230:                             if (currentLabelClass.isAssignableFrom(byte.class)) { testLabel = Byte.class; }
> 
> I assume here you want to box the primitive, right? If that's the case, consider using the JDK class `sun.invoke.util.Wrapper`, which has a factory `forBasicType` that takes a class. From there you can get the boxed type easily, in a single line.

Perfect! Exactly what I needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347256678
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347256224

From mbaesken at openjdk.org  Thu Oct  5 11:57:08 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Oct 2023 11:57:08 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5
In-Reply-To: 
References: 
Message-ID: 

On Thu, 5 Oct 2023 10:02:05 GMT, Joachim Kern  wrote:

> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
> 
> test TreeTest.test5(): failure
> java.lang.AssertionError: expected direct children expected [2] but found [3]
>         at org.testng.Assert.fail(Assert.java:99)
>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>         at org.testng.Assert.assertEquals(Assert.java:122)
>         at org.testng.Assert.assertEquals(Assert.java:907)
>         at TreeTest.test5(TreeTest.java:447)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>         at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>         at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>         at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>         at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>         at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>         at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>         at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>         at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>         at org.testng.TestRunner.privateRun(TestRunner.java:764)
>         at org.testng.TestRunner.run(TestRunner.java:585)
>         at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>         at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>         at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>         at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>         at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>         at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>         at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>         at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>         at org.testng.TestNG.runSuites(TestNG.java:1069)
>         at org.testng.TestNG.run(TestNG.java:1037)
>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(...

The naming unix_getChildren is now a little bit strange, because it is now just for Linux, not for AIX and also not for macOS.

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1748735407

From duke at openjdk.org  Thu Oct  5 12:11:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 5 Oct 2023 12:11:13 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 10:31:31 GMT, Raffaello Giulietti  wrote:

>> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid localized integers in radix-out-of-range exception messages.

In fact, the most commonly used one is that radix is 10 and coder is latin1, so we can make a fast-path

public final class Integer {
   public static int parseInt(String s) throws NumberFormatException {
        if (s != null && s.coder() == String.LATIN1) {
            byte[] value = s.value();
            int len = value.length;
            if (len == 0) {
                throw new NumberFormatException("");
            }
            int digit = ~0xFF;
            int i = 0;
            byte firstChar = value[i++];
            if (firstChar != '-' && firstChar != '+') {
                digit = DIGITS[firstChar & 0xFF];
            }
            if (digit >= 0 || digit == ~0xFF && len > 1) {
                int limit = firstChar != '-' ? MIN_VALUE + 1 : MIN_VALUE;
                int multmin = limit / 10;
                int result = -(digit & 0xFF);
                boolean inRange = true;
                /* Accumulating negatively avoids surprises near MAX_VALUE */
                while (i < len && (digit = DIGITS[value[i++] & 0xFF]) >= 0
                        && (inRange = result > multmin
                        || result == multmin && digit <= 10 * multmin - limit)) {
                    result = 10 * result - digit;
                }
                if (inRange && i == len && digit >= 0) {
                    return firstChar != '-' ? -result : result;
                }
            }
            throw NumberFormatException.forInputString(s, 10);
        }
        return parseInt(s, 10);
    }

   @Stable
    private static final byte[] DIGITS = new byte[] {
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1,  0,  1,  2,  3,  4,  5,  6,  7,  8,  9, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
            -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };
}


Performance numbers running on MacBook M1 Max are about 9% faster:

-Benchmark          (size)  Mode  Cnt  Score   Error  Units
-Integers.parseInt     500  avgt   15  2.480 ? 0.017  us/op

+Benchmark          (size)  Mode  Cnt  Score   Error  Units (fast-path)
+Integers.parseInt     500  avgt   15  2.270 ? 0.011  us/op
``

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

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1748753625

From alexey.ivanov at oracle.com  Thu Oct  5 12:15:32 2023
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Thu, 5 Oct 2023 13:15:32 +0100
Subject: RFC: 8309726: Reader::readString
In-Reply-To: <000001d99b8f$b6e1a4d0$24a4ee70$@eu>
References: <000001d99b8f$b6e1a4d0$24a4ee70$@eu>
Message-ID: 

Hi Markus,

You posted it to the wrong list, it belongs on core-libs-dev.

-- 
Regards,
Alexey

On 10/06/2023 12:35, Markus Karg wrote:
>
> By analyzing several existing applications I noticed that many of them 
> need to read a String from an input source (be it an input stream or a 
> reader), and there are a lot of solutions applied which all are more 
> or less suboptimal:
>
> * Files.readString(Path) - Fast, convenient, uses JLA.newStringNoRepl, 
> only works with files (not with sockets or other sources).
> * new String(inputStream.readAllBytes()) - Fast, complex, enforces 
> dealing with an array in user code, cannot use JLA.newStringNoRepl.
> * bufferedReader.lines().collect(StringBuilder::new, 
> StringBuilder::append, StringBuilder::append).toString(); - Complex, 
> enforces dealing with a stream in user code, doesn't use 
> JLA.newStringNoRepl.
> * reader.transferTo(stringWriter); stringWriter.toString(); - Medium 
> convient, medium performance, synchronized as it relies on 
> StringBuffer instead of StringBuilder.
> * Custom loop using char[] of various default sizes (some 8k, some 
> 16k, some configurable) - Slow, complex, doesn't use JLA.newStringNoRepl.
> * etc.
>
> Checking back with the particular authors of these applications I 
> noticed that what they all miss is (a) guidance which solution is 
> "best" (mostly thinking in speed, but also in reduced GC stress and 
> memory consumption), (b) something convenient like Files.readString() 
> but working with any reader implementation, not just with files.
>
> I think we can do better, hence I'd like to propose the introduction 
> of a new Reader::readString method. The benefits are:
> * Guidance. The introduction of this method is a clear signal to all 
> application programmers to use *this* one by default.
> * Convenience. It couldn't be any easier for the caller.
> * Performance. OpenJDK committers can optimize it for both, 
> convenience, speed, reduced GC stress, and memory consumption, at the 
> very same time.
> * Optimizable. Each Reader implementation can choose an algorithm 
> fitting best its own needs, while java.io.Reader itself provides a 
> convenient default implementation based on a loop over this.read().
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rgiulietti at openjdk.org  Thu Oct  5 12:27:12 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Oct 2023 12:27:12 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 10:31:31 GMT, Raffaello Giulietti  wrote:

>> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid localized integers in radix-out-of-range exception messages.

The aim of this PR is _not_ to make the code faster, but to make it more uniform. It turns out to be slightly faster even without special cases, but this was not the goal, but just a by-product of the simpler structure.
Over-reliance on micro benchmarks and obsession for speed is not a guidance for this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1748790454

From abimpoudis at openjdk.org  Thu Oct  5 15:13:57 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 15:13:57 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v10]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix `checkUnconditionallyExact` and adjust the type of numeric constants (to primitive type)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/c8b860d6..c041d208

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=08-09

  Stats: 11 lines in 2 files changed: 3 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Thu Oct  5 15:14:13 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 15:14:13 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
 
 <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>
Message-ID: 

On Thu, 5 Oct 2023 08:14:53 GMT, Aggelos Biboudis  wrote:

>> Aren't there cases here where the type of the expr is unconditional w.r.t. the type of the pattern (and so, no test is required) ? Perhaps the case I'm thinking of is dealt with one of the ifs at the beginning of this method.
>> 
>> I have to say I'm a bit confused by how this method is arranged. From a logical perspective I would expect first and foremost to test if the pattern type is a primitive, because that's the only case where Lower needs to do anything (right?).
>> 
>> Then you can have two cases: the expression has a reference type, in which case you need null check and unboxing. Or the expression has a primitive type.
>> 
>> In both cases you can be in a situation where the conversion is provably exact, so no need to call the exactness routine - or you can be in an inexact situation where a runtime test is required.
>> 
>> While I'm sure that is what happens in the above code, I think perhaps the various tests could be arranged in a way to make the above structure pop out a little more?
>
> Refactoring attempt No. 1 complete. I need to recheck the completeness of `checkUnconditionallyExact`. In a following commit.

`checkUnconditionallyExact` and dominance for constants were adjusted accordingly in https://github.com/openjdk/jdk/pull/15638/commits/c041d208a6fc6beaf785e8a400815fb4a7d08e78 ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347473254

From redestad at openjdk.org  Thu Oct  5 15:19:50 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 5 Oct 2023 15:19:50 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 10:31:31 GMT, Raffaello Giulietti  wrote:

>> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid localized integers in radix-out-of-range exception messages.

Changes look reasonable. The inline logic (such as writing to `inRange` on each loop iteration) makes the logic a bit harder to follow, but I think the improved consistency across implementations trumps this concern. 

I noticed that `parse*(CharSequence..)` and `parseUnsigned` aren't covered by current microbenchmark. That ought to be fixed.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16050#pullrequestreview-1660120147

From abimpoudis at openjdk.org  Thu Oct  5 15:24:40 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 15:24:40 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v11]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request with a new target base 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 primitive-patterns
 - Fix `checkUnconditionallyExact` and adjust the type of numeric constants (to primitive type)
 - Use sun.invoke.util.Wrapper in SwitchBootstraps
 - Declutter Lower.visitTypeTest
 - Simplify TypePairs
 - Rename exactness methods
 - Remove unnecessary disambiguation in TransPatterns and simplify Lower.visitTypeTest
 - Fix exhausts and equals in SwitchBootstraps
 - Merge branch 'master' into primitive-patterns
 - Implement type pairs to exactnessMethod name
 - ... and 2 more: https://git.openjdk.org/jdk/compare/228a2389...ff07aef9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/c041d208..ff07aef9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=09-10

  Stats: 7735 lines in 265 files changed: 3202 ins; 1731 del; 2802 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From asotona at openjdk.org  Thu Oct  5 15:25:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 5 Oct 2023 15:25:38 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v15]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with five additional commits since the last revision:

 - improved ClassFile constants javadoc
 - fixed AnnotationValue::of javadoc
 - fixed elements javadoc
 - Typo in BufWriter javadoc
 - cleanup in CustomAttribute

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/a6a73b37..7fe5db2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=13-14

  Stats: 401 lines in 13 files changed: 40 ins; 11 del; 350 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From rgiulietti at openjdk.org  Thu Oct  5 16:16:33 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Oct 2023 16:16:33 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v15]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Thu, 28 Sep 2023 21:40:17 GMT, ???  wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve the readability of parseArgument, suggestion from @rgiulietti

The parser looks good (but see the small proposed enhancements).

I'll continue with the rest tomorrow.

src/java.base/share/classes/java/util/Formatter.java line 2918:

> 2916:                 conversion = c;
> 2917:                 ++off;
> 2918:             }

Suggestion:

            } else if (isConversion(c)) {
                conversion = c;
                ++off;
            }

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

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1660250320
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1347671680

From rgiulietti at openjdk.org  Thu Oct  5 16:20:57 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Oct 2023 16:20:57 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v15]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Thu, 28 Sep 2023 21:40:17 GMT, ???  wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve the readability of parseArgument, suggestion from @rgiulietti

src/java.base/share/classes/java/util/Formatter.java line 2966:

> 2964: 
> 2965:         private int parsePrecision() {
> 2966:             // (\.\d+)?

Since processing of `'.'` is done by the caller, the regex pattern in this comment is confusing.
Either prefer handling `'.'` here (see [this](https://github.com/openjdk/jdk/pull/15776#issuecomment-1737986458)), or adjust the regex in the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1347679848

From naoto at openjdk.org  Thu Oct  5 17:39:58 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Oct 2023 17:39:58 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method
In-Reply-To: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
Message-ID: 

On Wed, 4 Oct 2023 22:56:28 GMT, Joe Wang  wrote:

> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.

src/java.xml/share/classes/javax/xml/catalog/CatalogManager.java line 101:

> 99:      * and {@code ignore}. {@code null} may be specified to indicate that the
> 100:      * {@code catalog} object's current {@link CatalogFeatures.Feature#RESOLVE RESOLVE}
> 101:      * value remains unchanged.

Supported values explanation and the behavior on `null` string may be moved into the method description body, as it explains how this method is supposed to work.

src/java.xml/share/classes/javax/xml/catalog/CatalogManager.java line 106:

> 104:      * @throws IllegalArgumentException if the value of the {@code resolve} property is
> 105:      * not a supported value or {@code null}.
> 106:      *

`@throws NPE` for `catalog==null` is needed

src/java.xml/share/classes/javax/xml/catalog/Util.java line 280:

> 278:      * Catalog implementation
> 279:      * @param uri the specified uri
> 280:      * @return Returns the absolute form of the specified uri

"Returns" may be redundant. Anyway, can this `Util` class be `final` and have private constructor not to be instantiated?

src/java.xml/share/classes/javax/xml/catalog/Util.java line 298:

> 296:             return temp;
> 297:         } catch (MalformedURLException ex) {
> 298:             // no action, shouldn't happen as the base has already been validated

If this "shouldn't happen", is that considered an Error, which should be reported?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16045#discussion_r1347735825
PR Review Comment: https://git.openjdk.org/jdk/pull/16045#discussion_r1347766234
PR Review Comment: https://git.openjdk.org/jdk/pull/16045#discussion_r1347749031
PR Review Comment: https://git.openjdk.org/jdk/pull/16045#discussion_r1347756200

From naoto at openjdk.org  Thu Oct  5 18:04:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Oct 2023 18:04:32 GMT
Subject: RFR: 8317471: ListFormat::parseObject() spec can be improved on
 parsePosition valid values
Message-ID: 

Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

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

Commit messages:
 - initial commit

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

PR: https://git.openjdk.org/jdk/pull/16063

From kvn at openjdk.org  Thu Oct  5 18:50:30 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 5 Oct 2023 18:50:30 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v41]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 16:53:21 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if

In general it looks good. I have some code style comments and file name change request.
After you fix that I will need to rerun testing for it before approval.

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

> 4181: 
> 4182:   // Load x86_64_sort library on supported hardware to enable avx512 sort and partition intrinsics
> 4183:     if (UseAVX > 2 && VM_Version::supports_avx512dq()) {

Indention (spacing) is wrong for lines 4183-4190 after you moved check.

src/hotspot/share/opto/library_call.cpp line 5372:

> 5370: bool LibraryCallKit::inline_array_partition() {
> 5371: 
> 5372:   address stubAddr = nullptr;

Move this declaration to first assignment at line 5387.

src/hotspot/share/opto/library_call.cpp line 5374:

> 5372:   address stubAddr = nullptr;
> 5373:   const char *stubName;
> 5374:   stubName = "array_partition_stub";

It could one line.

src/hotspot/share/opto/library_call.cpp line 5400:

> 5398: 
> 5399:   // create the pivotIndices array of type int and size = 2
> 5400:   Node* pivotIndices = nullptr;

Move to assignment at line 5403.

src/hotspot/share/opto/library_call.cpp line 5414:

> 5412:   make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::array_partition_Type(),
> 5413:                     stubAddr, stubName, TypePtr::BOTTOM,
> 5414:                     obj_adr, elemType, fromIndex, toIndex, pivotIndices_adr, indexPivot1, indexPivot2);

May be put `indexPivot*` argument on new line for fit screen better.

src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp line 4:

> 2:  * Copyright (c) 2021, 2023, Intel Corporation. All rights reserved.
> 3:  * Copyright (c) 2021 Serge Sans Paille. All rights reserved.
> 4:  * Intel x86-simd-sort source code.

I don't think this line here and in other new files will pass our Copyright header checker. Do you need this line here? You do have comment below `This implementation is based on x86-simd-sort`.
`DO NOT ALTER ..` line should immediately follow `Copyright` lines.

src/java.base/linux/native/libsimdsort/avxsort_linux_x86.cpp line 1:

> 1: /*

I think this file name should follow pattern of other files: `avx512-linux-qsort.cpp

src/java.base/share/classes/java/util/DualPivotQuicksort.java line 418:

> 416: 
> 417:         /*
> 418:         * The first and the last elements to be sorted are moved

Misaligned `/*` here and several places later. `*` should be aligned.

src/java.base/share/classes/java/util/DualPivotQuicksort.java line 1353:

> 1351:         /*
> 1352:             * Swap the pivot into its final position.
> 1353:             */

Indent

src/java.base/share/classes/java/util/DualPivotQuicksort.java line 2941:

> 2939:         /*
> 2940:             * Swap the pivot into its final position.
> 2941:             */

indent

src/java.base/share/classes/java/util/DualPivotQuicksort.java line 3794:

> 3792:         /*
> 3793:             * Swap the pivot into its final position.
> 3794:             */

Indent.

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

PR Review: https://git.openjdk.org/jdk/pull/14227#pullrequestreview-1660450589
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347808019
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347810630
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347809581
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347814187
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347816297
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347830769
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347834135
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347828096
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347824813
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347823957
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1347823053

From iris at openjdk.org  Thu Oct  5 20:02:05 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 5 Oct 2023 20:02:05 GMT
Subject: RFR: 8317471: ListFormat::parseObject() spec can be improved on
 parsePosition valid values
In-Reply-To: 
References: 
Message-ID: <6IcMmt6-fjIGGr0yJKVahP4UBhOLuhpQNEkCEPjKWYg=.294ae254-11aa-4020-9cf7-53f54faf5442@github.com>

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato  wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

Documents existing behaviour.  Associated CSR also Reviewed.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16063#pullrequestreview-1660615062

From duke at openjdk.org  Thu Oct  5 20:02:44 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 5 Oct 2023 20:02:44 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v16]
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
Message-ID: 

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

??? has updated the pull request incrementally with two additional commits since the last revision:

 - add copyright info
 - Improve the readability, suggestion from @rgiulietti

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/ad7f3bd1..7a1cd112

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=14-15

  Stats: 5 lines in 2 files changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15776/head:pull/15776

PR: https://git.openjdk.org/jdk/pull/15776

From lancea at openjdk.org  Thu Oct  5 20:11:00 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 5 Oct 2023 20:11:00 GMT
Subject: RFR: 8317471: ListFormat::parseObject() spec can be improved on
 parsePosition valid values
In-Reply-To: 
References: 
Message-ID: <_5Qk3vQ7EGCveaJ5BPtTeh2TnE4N88UF5XLTVIsQbPQ=.b74b9369-73bc-4385-a4b0-6c6ccefd6329@github.com>

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato  wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16063#pullrequestreview-1660626757

From jlu at openjdk.org  Thu Oct  5 21:04:26 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Oct 2023 21:04:26 GMT
Subject: RFR: JDK-8317631: Refactor ChoiceFormat tests to use JUnit
Message-ID: 

Please review this PR which refactors the ChoiceFormat tests to use JUnit.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/16065/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16065&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317631
  Stats: 141 lines in 3 files changed: 73 ins; 39 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/16065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16065/head:pull/16065

PR: https://git.openjdk.org/jdk/pull/16065

From joehw at openjdk.org  Thu Oct  5 21:35:59 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 5 Oct 2023 21:35:59 GMT
Subject: RFR: 8317471: ListFormat::parseObject() spec can be improved on
 parsePosition valid values
In-Reply-To: 
References: 
Message-ID: 

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato  wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16063#pullrequestreview-1660771766

From duke at openjdk.org  Thu Oct  5 23:01:21 2023
From: duke at openjdk.org (duke)
Date: Thu, 5 Oct 2023 23:01:21 GMT
Subject: Withdrawn: 8303762: [vectorapi] Intrinsification of Vector.slice
In-Reply-To: 
References: 
Message-ID: 

On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai  wrote:

> `Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to the correct positions. Slicing is also used in text processing such as utf8 and utf16 validation. x86 starting from SSSE3 has `palignr` which does vector slicing very efficiently. As a result, I think it is beneficial to add a C2 node for this operation as well as intrinsify `Vector::slice` method.
> 
> A slice is currently implemented as `v2.rearrange(iota).blend(v1.rearrange(iota), blendMask)` which requires preparation of the index vector and the blending mask. Even with the preparations being hoisted out of the loops, microbenchmarks show improvement using the slice instrinsics. Some have tremendous increases in throughput due to the limitation that a mask of length 2 cannot currently be intrinsified, leading to falling back to the Java implementations.
> 
> Please take a look and have some reviews. Thank you very much.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12909

From naoto at openjdk.org  Thu Oct  5 23:09:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Oct 2023 23:09:10 GMT
Subject: Integrated: 8317443: StackOverflowError on calling
 ListFormat::getInstance() for Norwegian locales
In-Reply-To: 
References: 
Message-ID: 

On Wed, 4 Oct 2023 17:17:57 GMT, Naoto Sato  wrote:

> Please review the fix to the subject issue. This was found during upgrading CLDR to v44, in which some list patterns are missing (thus to be inherited from parents) in Norwegian locales which could end up with infinite parent lookup. Avoiding the recursive call and changing it to a plain loop fixes the issue.
> Not related to this issue, the test case has been corrected to work with any locale. Currently, it assumes English.

This pull request has now been integrated.

Changeset: 8a30c2a9
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/8a30c2a9b2ef3f069e82061e6db113e259a75bcd
Stats:     15 lines in 2 files changed: 2 ins; 0 del; 13 mod

8317443: StackOverflowError on calling ListFormat::getInstance() for Norwegian locales

Reviewed-by: joehw

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

PR: https://git.openjdk.org/jdk/pull/16042

From duke at openjdk.org  Thu Oct  5 23:36:48 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 5 Oct 2023 23:36:48 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
Message-ID: 

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
> 
> 
> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
> 
> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
> |	---	|	---	|	---	|	---	|	---	|
> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
> |	ArraysSort.longSort	|	1000	|	10.449	|	6.239	|	1.7	|
> |	ArraysSort.longSort	|	10000	|	307.074	|	70.284	|	**4.4**	|
> |	ArraysSor...

Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - fix code style and formatting
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
 - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
 - change variable names of indexPivot* to pivotIndex*
 - Update DualPivotQuicksort.java
 - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
 - Remove the unnecessary exception in single pivot partitioning fallback method
 - Move functional interfaces close to the associated methods
 - Refactor the sort and partition intrinsics to accept method references for fallback functions
 - Refactor stub handling to use a generic function for all types
 - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86

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

Changes: https://git.openjdk.org/jdk/pull/14227/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=41
  Stats: 3410 lines in 22 files changed: 2902 ins; 292 del; 216 mod
  Patch: https://git.openjdk.org/jdk/pull/14227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14227/head:pull/14227

PR: https://git.openjdk.org/jdk/pull/14227

From duke at openjdk.org  Thu Oct  5 23:46:26 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 5 Oct 2023 23:46:26 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v41]
In-Reply-To: 
References: 
 
 
Message-ID: <2PV5IKUd6m3cGe3AG_P2S_hv9PrxgXJ2h-Sr7aNSjFc=.6fbe82fc-d27b-464f-93c1-a78c07e3a470@github.com>

On Thu, 5 Oct 2023 18:46:46 GMT, Vladimir Kozlov  wrote:

> In general it looks good. I have some code style comments and file name change request. After you fix that I will need to rerun testing for it before approval.

Hello Vladimir (@vnkozlov),

Thank you for the suggestions related to the code style and formatting!
Please see all the suggested changes incorporated into the latest commit that was just pushed.

Thanks,
Vamsi

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4183:
> 
>> 4181: 
>> 4182:   // Load x86_64_sort library on supported hardware to enable avx512 sort and partition intrinsics
>> 4183:     if (UseAVX > 2 && VM_Version::supports_avx512dq()) {
> 
> Indention (spacing) is wrong for lines 4183-4190 after you moved check.

Fixed the indentation. Please see the latest commit that was pushed.

> src/hotspot/share/opto/library_call.cpp line 5372:
> 
>> 5370: bool LibraryCallKit::inline_array_partition() {
>> 5371: 
>> 5372:   address stubAddr = nullptr;
> 
> Move this declaration to first assignment at line 5387.

Fixed the declaration. Please see the latest commit that was pushed.

> src/hotspot/share/opto/library_call.cpp line 5374:
> 
>> 5372:   address stubAddr = nullptr;
>> 5373:   const char *stubName;
>> 5374:   stubName = "array_partition_stub";
> 
> It could one line.

Fixed the assignment. Please see the latest commit that was pushed.

> src/hotspot/share/opto/library_call.cpp line 5400:
> 
>> 5398: 
>> 5399:   // create the pivotIndices array of type int and size = 2
>> 5400:   Node* pivotIndices = nullptr;
> 
> Move to assignment at line 5403.

Moved the assignment. Please see the latest commit that was pushed.

> src/hotspot/share/opto/library_call.cpp line 5414:
> 
>> 5412:   make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::array_partition_Type(),
>> 5413:                     stubAddr, stubName, TypePtr::BOTTOM,
>> 5414:                     obj_adr, elemType, fromIndex, toIndex, pivotIndices_adr, indexPivot1, indexPivot2);
> 
> May be put `indexPivot*` argument on new line for fit screen better.

Fixed the indentation. Please see the latest commit that was pushed.

> src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp line 4:
> 
>> 2:  * Copyright (c) 2021, 2023, Intel Corporation. All rights reserved.
>> 3:  * Copyright (c) 2021 Serge Sans Paille. All rights reserved.
>> 4:  * Intel x86-simd-sort source code.
> 
> I don't think this line here and in other new files will pass our Copyright header checker. Do you need this line here? You do have comment below `This implementation is based on x86-simd-sort`.
> `DO NOT ALTER ..` line should immediately follow `Copyright` lines.

Fixed the copyright headers. Please see the latest commit that was pushed.

> src/java.base/linux/native/libsimdsort/avxsort_linux_x86.cpp line 1:
> 
>> 1: /*
> 
> I think this file name should follow pattern of other files: `avx512-linux-qsort.cpp

Changed the name of the file as suggested. Please see the latest commit that was pushed.

> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 418:
> 
>> 416: 
>> 417:         /*
>> 418:         * The first and the last elements to be sorted are moved
> 
> Misaligned `/*` here and several places later. `*` should be aligned.

Fixed the alignment for `/*` and `*` in various places. Please see the latest commit that was pushed.

> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 1353:
> 
>> 1351:         /*
>> 1352:             * Swap the pivot into its final position.
>> 1353:             */
> 
> Indent

Fixed the indentation. Please see the latest commit that was pushed.

> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 2941:
> 
>> 2939:         /*
>> 2940:             * Swap the pivot into its final position.
>> 2941:             */
> 
> indent

Fixed the indentation. Please see the latest commit that was pushed.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1749797401
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348105761
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348106048
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348105919
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348106228
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348106326
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348107205
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348106960
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348106765
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348106515
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1348106465

From kvn at openjdk.org  Thu Oct  5 23:57:23 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 5 Oct 2023 23:57:23 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v41]
In-Reply-To: <2PV5IKUd6m3cGe3AG_P2S_hv9PrxgXJ2h-Sr7aNSjFc=.6fbe82fc-d27b-464f-93c1-a78c07e3a470@github.com>
References: 
 
 
 <2PV5IKUd6m3cGe3AG_P2S_hv9PrxgXJ2h-Sr7aNSjFc=.6fbe82fc-d27b-464f-93c1-a78c07e3a470@github.com>
Message-ID: <6ZpCbTIkpPhLKTmwNH3OfCl9R2bg8hpr230oFCAmYHg=.ec5d2620-8548-4125-b155-782a8a137e96@github.com>

On Thu, 5 Oct 2023 23:39:20 GMT, Srinivas Vamsi Parasa  wrote:

>> In general it looks good. I have some code style comments and file name change request.
>> After you fix that I will need to rerun testing for it before approval.
>
>> In general it looks good. I have some code style comments and file name change request. After you fix that I will need to rerun testing for it before approval.
> 
> Hello Vladimir (@vnkozlov),
> 
> Thank you for the suggestions related to the code style and formatting!
> Please see all the suggested changes incorporated into the latest commit that was just pushed.
> 
> Thanks,
> Vamsi

Thank you @vamsi-parasa. I will start new testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1749806333

From jpai at openjdk.org  Fri Oct  6 01:45:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Oct 2023 01:45:59 GMT
Subject: RFR: 8317634: Introduce the ability to exclude modules from
 dedup-legal-notices plugin of jlink
Message-ID: 

Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/JDK-8317634?

The change in this commit introduces a new `exclude-modules` argument to the `dedup-legal-notices` jlink plugin. This optional argument takes a comma separated values of module names. These module names are then excluded from the de-duplication of license notice files during image generation.

Two new test methods have been added to the existing `LegalFilePluginTest` jtreg test case to verify this implementation. Existing tests in `test/jdk/tools/jlink` continue to pass. tier testing is currently in progress.

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

Commit messages:
 - introduce an argument for --dedup-legal-notices option of jlink to optionally exclude certain modules' license files from de-duplication

Changes: https://git.openjdk.org/jdk/pull/16066/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317634
  Stats: 168 lines in 2 files changed: 161 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16066/head:pull/16066

PR: https://git.openjdk.org/jdk/pull/16066

From jpai at openjdk.org  Fri Oct  6 02:03:47 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Oct 2023 02:03:47 GMT
Subject: RFR: 8317634: Introduce the ability to exclude modules from
 dedup-legal-notices plugin of jlink [v2]
In-Reply-To: 
References: 
Message-ID: <8tjzRwraoD6s2Xe2m2KFJdbCVbAcAacC8YiD_XPig_I=.7404b3c7-5c72-4ddc-8e46-f6e9d59f486d@github.com>

> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/JDK-8317634?
> 
> The change in this commit introduces a new `exclude-modules` argument to the `dedup-legal-notices` jlink plugin. This optional argument takes a comma separated values of module names. These module names are then excluded from the de-duplication of license notice files during image generation.
> 
> Two new test methods have been added to the existing `LegalFilePluginTest` jtreg test case to verify this implementation. Existing tests in `test/jdk/tools/jlink` continue to pass. tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  update jlink plugin.properties to include the new argument

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16066/files
  - new: https://git.openjdk.org/jdk/pull/16066/files/182ef8b1..510a3ecf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16066&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16066&range=00-01

  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16066/head:pull/16066

PR: https://git.openjdk.org/jdk/pull/16066

From jpai at openjdk.org  Fri Oct  6 02:22:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Oct 2023 02:22:52 GMT
Subject: RFR: 8317634: Introduce the ability to exclude modules from
 dedup-legal-notices plugin of jlink [v3]
In-Reply-To: 
References: 
Message-ID: 

> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/JDK-8317634?
> 
> The change in this commit introduces a new `exclude-modules` argument to the `dedup-legal-notices` jlink plugin. This optional argument takes a comma separated values of module names. These module names are then excluded from the de-duplication of license notice files during image generation.
> 
> Two new test methods have been added to the existing `LegalFilePluginTest` jtreg test case to verify this implementation. Existing tests in `test/jdk/tools/jlink` continue to pass. tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  minor changes to the text in plugin.properties for the new argument, to render better on command line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16066/files
  - new: https://git.openjdk.org/jdk/pull/16066/files/510a3ecf..980b371d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16066&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16066&range=01-02

  Stats: 12 lines in 1 file changed: 3 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16066/head:pull/16066

PR: https://git.openjdk.org/jdk/pull/16066

From qamai at openjdk.org  Fri Oct  6 03:09:13 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Oct 2023 03:09:13 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 10:31:31 GMT, Raffaello Giulietti  wrote:

>> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid localized integers in radix-out-of-range exception messages.

src/java.base/share/classes/java/lang/Integer.java line 767:

> 765:             /* Use MIN_VALUE + x < MIN_VALUE + y as unsigned x < y comparison */
> 766:             while (i < len && (digit = digit(s.charAt(i++), radix)) >= 0
> 767:                     && (inRange = MIN_VALUE + result < MIN_VALUE + multmax

`compareUnsigned(result, multmax) < 0` would be better here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1348196974

From qamai at openjdk.org  Fri Oct  6 03:20:10 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Oct 2023 03:20:10 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 10:31:31 GMT, Raffaello Giulietti  wrote:

>> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid localized integers in radix-out-of-range exception messages.

Could we parse the signed int by parsing the unsigned suffix then prepend the sign? It will unify the code path of `parseInt` and `parseUnsignedInt`. 

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1749928353

From alanb at openjdk.org  Fri Oct  6 04:36:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Oct 2023 04:36:01 GMT
Subject: RFR: 8317634: Introduce the ability to exclude modules from
 dedup-legal-notices plugin of jlink [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 02:22:52 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/JDK-8317634?
>> 
>> The change in this commit introduces a new `exclude-modules` argument to the `dedup-legal-notices` jlink plugin. This optional argument takes a comma separated values of module names. These module names are then excluded from the de-duplication of license notice files during image generation.
>> 
>> Two new test methods have been added to the existing `LegalFilePluginTest` jtreg test case to verify this implementation. Existing tests in `test/jdk/tools/jlink` continue to pass. tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes to the text in plugin.properties for the new argument, to render better on command line

The bug has "On platforms (like Windows) where symbolic links isn't available" but Windows does have sym links (on NTFS). I think it's important that Mandy agrees with the problem and your proposal as, on initial look anyway, this seems a strange change and I think needs a better description to make the case.

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

PR Comment: https://git.openjdk.org/jdk/pull/16066#issuecomment-1749969306

From jpai at openjdk.org  Fri Oct  6 05:30:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 6 Oct 2023 05:30:59 GMT
Subject: RFR: 8317634: Introduce the ability to exclude modules from
 dedup-legal-notices plugin of jlink [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 02:22:52 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/JDK-8317634?
>> 
>> The change in this commit introduces a new `exclude-modules` argument to the `dedup-legal-notices` jlink plugin. This optional argument takes a comma separated values of module names. These module names are then excluded from the de-duplication of license notice files during image generation.
>> 
>> (Edited to add some context) The motivation for this change is discussed here https://github.com/openjdk/jdk/pull/13686#issuecomment-1747301865
>> 
>> Two new test methods have been added to the existing `LegalFilePluginTest` jtreg test case to verify this implementation. Existing tests in `test/jdk/tools/jlink` continue to pass. tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes to the text in plugin.properties for the new argument, to render better on command line

Hello Alan, the proposal to introduce this enhancement was based on the discussion in the other PR here https://github.com/openjdk/jdk/pull/13686#issuecomment-1747301865. Mandy suggested that we could pursue this approach to allow certain modules (like jdk.javadoc) to disable de-duplication so that they can then (at runtime) have the actual legal notice files available to them without having to resort to brittle tricks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16066#issuecomment-1750005350

From alanb at openjdk.org  Fri Oct  6 05:45:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Oct 2023 05:45:03 GMT
Subject: RFR: 8317634: Introduce the ability to exclude modules from
 dedup-legal-notices plugin of jlink [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 02:22:52 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/JDK-8317634?
>> 
>> The change in this commit introduces a new `exclude-modules` argument to the `dedup-legal-notices` jlink plugin. This optional argument takes a comma separated values of module names. These module names are then excluded from the de-duplication of license notice files during image generation.
>> 
>> (Edited to add some context) The motivation for this change is discussed here https://github.com/openjdk/jdk/pull/13686#issuecomment-1747301865
>> 
>> Two new test methods have been added to the existing `LegalFilePluginTest` jtreg test case to verify this implementation. Existing tests in `test/jdk/tools/jlink` continue to pass. tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes to the text in plugin.properties for the new argument, to render better on command line

If Mandy is onboard then okay but I think the JBS issue and this PR need a clear description sto explain what the issue is before describing the proposed solution. It would also be useful to know how this plugin behaves when the user running is jlink does have permission to create sym links.

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

PR Comment: https://git.openjdk.org/jdk/pull/16066#issuecomment-1750014584

From duke at openjdk.org  Fri Oct  6 09:08:16 2023
From: duke at openjdk.org (Martin Stypinski)
Date: Fri, 6 Oct 2023 09:08:16 GMT
Subject: RFR: 8314544: Matrix multiple benchmark using Vector API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Aug 2023 03:55:42 GMT, Martin Stypinski  wrote:

>> Added a bunch of different implementations for Vector API Matrix Multiplications:
>> 
>> - Baseline
>> - Blocked (Cache Local)
>> - FMA
>> - Vector API Simple Implementation
>> - Vector API Blocked Implementation
>> 
>> Commit was discussed with @PaulSandoz
>
> Martin Stypinski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - changed for consistency
>  - improved some RandomGenerator & unuseed Imports

fixed typo.

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

PR Comment: https://git.openjdk.org/jdk/pull/15338#issuecomment-1750195385

From rgiulietti at openjdk.org  Fri Oct  6 09:42:16 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 6 Oct 2023 09:42:16 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 6 Oct 2023 03:06:08 GMT, Quan Anh Mai  wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid localized integers in radix-out-of-range exception messages.
>
> src/java.base/share/classes/java/lang/Integer.java line 767:
> 
>> 765:             /* Use MIN_VALUE + x < MIN_VALUE + y as unsigned x < y comparison */
>> 766:             while (i < len && (digit = digit(s.charAt(i++), radix)) >= 0
>> 767:                     && (inRange = MIN_VALUE + result < MIN_VALUE + multmax
> 
> `compareUnsigned(result, multmax) < 0` would be better here.

`MIN_VALUE + result < MIN_VALUE + multmax` is C2-compiled to a single unsigned compare instruction (@merykitty [you should know](https://github.com/openjdk/jdk/pull/6101) ;-) )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1348468468

From rgiulietti at openjdk.org  Fri Oct  6 10:21:19 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 6 Oct 2023 10:21:19 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <3LLn7ieKgy3GalyXcJfC7I-44l5DjFu6js_lQIX7bOY=.90b12b72-fc0e-473d-a975-54b4d437179b@github.com>

On Fri, 6 Oct 2023 03:16:50 GMT, Quan Anh Mai  wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid localized integers in radix-out-of-range exception messages.
>
> Could we parse the signed int by parsing the unsigned suffix then prepend the sign? It will unify the code path of `parseInt` and `parseUnsignedInt`. 
> 
> Thanks.

@merykitty For a `String` input that would mean copying the suffix, which could be quite long, or make use of the method that accepts a `CharSequence`, which has different (although more complete) exception messages. Perhaps in a followup PR.

What would be _really_ nice is to be able to write, for example (leaving apart the exception messages issue above)

public static int parseInt(String s, int radix)
                throws NumberFormatException {
    return parseInt(s, 0, s.length(), radix);  // delegate to the CharSequence method
}

and leave it to the runtime compiler to perform something similar to
* make a copy of the `parseInt(CharSequence,int,int,int)` code into `parseInt(String,int)`
* adapt the copy to the `String` case by replacing `invokeinterface` for `charAt()` with `invokevirtual`, which can be further optimized to direct invocation because `String` is final, and eventually inlined perfectly.

Currently, that does not seem to happen, but I might be wrong.
This would spare us 4 code duplications here, and perhaps in many other places where we have almost identical methods for `String` and `CharSequence`.

> src/java.base/share/classes/java/lang/Integer.java line 767:
> 
>> 765:             /* Use MIN_VALUE + x < MIN_VALUE + y as unsigned x < y comparison */
>> 766:             while (i < len && (digit = digit(s.charAt(i++), radix)) >= 0
>> 767:                     && (inRange = MIN_VALUE + result < MIN_VALUE + multmax
> 
> `compareUnsigned(result, multmax) < 0` would be better here.

Oops @merykitty, I see right now that `compareUnsigned` is an intrinsic, so I'll give it a try.

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

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1750314751
PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1348509327

From qamai at openjdk.org  Fri Oct  6 10:21:22 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Oct 2023 10:21:22 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: <3LLn7ieKgy3GalyXcJfC7I-44l5DjFu6js_lQIX7bOY=.90b12b72-fc0e-473d-a975-54b4d437179b@github.com>
References: 
 
 
 <3LLn7ieKgy3GalyXcJfC7I-44l5DjFu6js_lQIX7bOY=.90b12b72-fc0e-473d-a975-54b4d437179b@github.com>
Message-ID: 

On Fri, 6 Oct 2023 09:53:46 GMT, Raffaello Giulietti  wrote:

>> Could we parse the signed int by parsing the unsigned suffix then prepend the sign? It will unify the code path of `parseInt` and `parseUnsignedInt`. 
>> 
>> Thanks.
>
> @merykitty For a `String` input that would mean copying the suffix, which could be quite long, or make use of the method that accepts a `CharSequence`, which has different (although more complete) exception messages. Perhaps in a followup PR.
> 
> What would be _really_ nice is to be able to write, for example (leaving apart the exception messages issue above)
> 
> public static int parseInt(String s, int radix)
>                 throws NumberFormatException {
>     return parseInt(s, 0, s.length(), radix);  // delegate to the CharSequence method
> }
> 
> and leave it to the runtime compiler to perform something similar to
> * make a copy of the `parseInt(CharSequence,int,int,int)` code into `parseInt(String,int)`
> * adapt the copy to the `String` case by replacing `invokeinterface` for `charAt()` with `invokevirtual`, which can be further optimized to direct invocation because `String` is final, and eventually inlined perfectly.
> 
> Currently, that does not seem to happen, but I might be wrong.
> This would spare us 4 code duplications here, and perhaps in many other places where we have almost identical methods for `String` and `CharSequence`.

@rgiulietti We can do the same thing as the Vector API does, that is to have a private `parseInt(CharSequence, int, int, int)` that is annotated with `@ForceInline`. When called from `parseInt(String, int)`, the compiler, after inlining the former method, can devirtualise all calls to `charAt`, etc. This is like a poor man workaround for monomorphism.

    @ForceInline
    private int parseUnsignedInt(CharSequence, int, int, int) {}

    public int parseUnsignedInt(String s, int radix) {
        return parseUnsignedInt(s, 0, s.length(), radix); // After inlining, this call behaves as if it is a parseUnsignedInt(String, int, int, int)
    }

Thanks.

>> src/java.base/share/classes/java/lang/Integer.java line 767:
>> 
>>> 765:             /* Use MIN_VALUE + x < MIN_VALUE + y as unsigned x < y comparison */
>>> 766:             while (i < len && (digit = digit(s.charAt(i++), radix)) >= 0
>>> 767:                     && (inRange = MIN_VALUE + result < MIN_VALUE + multmax
>> 
>> `compareUnsigned(result, multmax) < 0` would be better here.
>
> Oops @merykitty, I see right now that `compareUnsigned` is an intrinsic, so I'll give it a try.

It's not really about performance, I just think that it is more readable the other way.

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

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1750342409
PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1348515434

From rgiulietti at openjdk.org  Fri Oct  6 10:21:22 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 6 Oct 2023 10:21:22 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
 
 <3LLn7ieKgy3GalyXcJfC7I-44l5DjFu6js_lQIX7bOY=.90b12b72-fc0e-473d-a975-54b4d437179b@github.com>
 
Message-ID: 

On Fri, 6 Oct 2023 10:12:53 GMT, Quan Anh Mai  wrote:

>> @merykitty For a `String` input that would mean copying the suffix, which could be quite long, or make use of the method that accepts a `CharSequence`, which has different (although more complete) exception messages. Perhaps in a followup PR.
>> 
>> What would be _really_ nice is to be able to write, for example (leaving apart the exception messages issue above)
>> 
>> public static int parseInt(String s, int radix)
>>                 throws NumberFormatException {
>>     return parseInt(s, 0, s.length(), radix);  // delegate to the CharSequence method
>> }
>> 
>> and leave it to the runtime compiler to perform something similar to
>> * make a copy of the `parseInt(CharSequence,int,int,int)` code into `parseInt(String,int)`
>> * adapt the copy to the `String` case by replacing `invokeinterface` for `charAt()` with `invokevirtual`, which can be further optimized to direct invocation because `String` is final, and eventually inlined perfectly.
>> 
>> Currently, that does not seem to happen, but I might be wrong.
>> This would spare us 4 code duplications here, and perhaps in many other places where we have almost identical methods for `String` and `CharSequence`.
>
> @rgiulietti We can do the same thing as the Vector API does, that is to have a private `parseInt(CharSequence, int, int, int)` that is annotated with `@ForceInline`. When called from `parseInt(String, int)`, the compiler, after inlining the former method, can devirtualise all calls to `charAt`, etc. This is like a poor man workaround for monomorphism.
> 
>     @ForceInline
>     private int parseUnsignedInt(CharSequence, int, int, int) {}
> 
>     public int parseUnsignedInt(String s, int radix) {
>         return parseUnsignedInt(s, 0, s.length(), radix); // After inlining, this call behaves as if it is a parseUnsignedInt(String, int, int, int)
>     }
> 
> Thanks.

@merykitty Interesting. I'll prepare a followup PR in the near future.

>> Oops @merykitty, I see right now that `compareUnsigned` is an intrinsic, so I'll give it a try.
>
> It's not really about performance, I just think that it is more readable the other way.

Well, two lines above the usage there's a comment that should help the reader...

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

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1750348693
PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1348523537

From sgehwolf at openjdk.org  Fri Oct  6 11:17:32 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 6 Oct 2023 11:17:32 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v4]
In-Reply-To: 
References: 
Message-ID: <14Wx1A8qwJUvYXbf46qhGkp3sQe4aUcZoY0pSQEvjsg=.791c5d72-9ffc-4618-ba46-b338f36a92b7@github.com>

> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.jmod        jdk.unsupported...

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

 - Work-around JDK-8317609 (jdk.jcmd module doesn't verify)
 - Fix tests after merge
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Implementation for run-image link and single-hop
   
   This uses a stamp file in 'lib/modules' jimage in order to recognize
   multi-hop links. However, this has the caveat of no longer producing
   reproducible builds as compared to a packaged module-based link.
   
   Add an option to allow for multi-hop, which disables the stamp file
   addition and makes it reproducible again.
 - Exit the jlink on modified files by default
   
   This is configurable so add tests for both scenarios.
 - Use 'run-image' as the term shown with --verbose
 - 8311302: Allow for jlinking a custom runtime without packaged modules being present

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/738b8a31..2e73e300

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=02-03

  Stats: 144634 lines in 4016 files changed: 69362 ins; 29938 del; 45334 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From duke at openjdk.org  Fri Oct  6 11:17:47 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 6 Oct 2023 11:17:47 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 10:31:31 GMT, Raffaello Giulietti  wrote:

>> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid localized integers in radix-out-of-range exception messages.

The reason parseUnsignedInt(CharSequence s, int beginIndex, int endIndex, int radix) cannot be inlined is because codeSize 350 is greater than default FreqInlineSize 325. Refactoring the exception handling code can be smaller than 325 without using @ForceInline.

Refactoring the code related to exception handling can make the code smaller and easier to be inlined. The code for constructing exceptions in these methods is encapsulated into methods and can be easily maintained together.

https://github.com/rgiulietti/jdk/pull/1

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

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1750369837
PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1750391108

From qamai at openjdk.org  Fri Oct  6 11:17:48 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Oct 2023 11:17:48 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 6 Oct 2023 10:28:31 GMT, ???  wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid localized integers in radix-out-of-range exception messages.
>
> The reason parseUnsignedInt(CharSequence s, int beginIndex, int endIndex, int radix) cannot be inlined is because codeSize 350 is greater than default FreqInlineSize 325. Refactoring the exception handling code can be smaller than 325 without using @ForceInline.

@wenshao There are a lot of factors affecting the inlineability of a method and it is not advisable to rely on a method being inlined apart from really simple ones or those that are marked with `@ForceInline`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1750379747

From abimpoudis at openjdk.org  Fri Oct  6 11:23:47 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 6 Oct 2023 11:23:47 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v12]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix Lower.visitTypeTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ff07aef9..01ebecd9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=10-11

  Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From mcimadamore at openjdk.org  Fri Oct  6 11:40:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Oct 2023 11:40:54 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
 
 <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>
 
Message-ID: <1HWKJZ2MQ3GUFLV2syrWzOMTEsSGH_JNYjplw7Tql_Y=.60d43713-3eac-4042-a8ad-ab9347ea3589@github.com>

On Thu, 5 Oct 2023 14:00:12 GMT, Aggelos Biboudis  wrote:

>> Refactoring attempt No. 1 complete. I need to recheck the completeness of `checkUnconditionallyExact`. In a following commit.
>
> `checkUnconditionallyExact` and dominance for constants were adjusted accordingly in https://github.com/openjdk/jdk/pull/15638/commits/c041d208a6fc6beaf785e8a400815fb4a7d08e78 ?

The new logic is much better and simpler to follow - thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1348608306

From mcimadamore at openjdk.org  Fri Oct  6 11:40:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Oct 2023 11:40:56 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <8MevNyryZdtgfndhK_ASX5NGLaXesVGfJ89iSLYJyzg=.cd11e37d-bba0-4d02-a044-addb706f6852@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
 <8MevNyryZdtgfndhK_ASX5NGLaXesVGfJ89iSLYJyzg=.cd11e37d-bba0-4d02-a044-addb706f6852@github.com>
Message-ID: 

On Wed, 4 Oct 2023 10:08:31 GMT, Aggelos Biboudis  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3001:
>> 
>>> 2999:     }
>>> 3000: 
>>> 3001:     static class TypePairs {
>> 
>> I believe this could be a record between two TypeSymbols? Then you could have an additional constructor that takes two types and retrieves their `tsym` and call the canonical constructor (and then you can drop equals/hashcode).
>
> Done and simplified https://github.com/openjdk/jdk/pull/15638/commits/ef98c040c909981077936c6ff4280b6da04b8c24. Do you think we can simplify further (or benefit at all) by also eliminating duplication between SwitchBootstrap and Lower?

I don't think there's an easy easy way to deduplicate the code, as the code occurs in two different modules, so it's messy (as bootstrap javac compilation cannot depend on stuff that is in the latest latest JDK, as it has to compile against JDK N-1, and, on the other hand, java.base cannot depend on any other modules). So, leave it as is, maybe add a comment that the code should stay in sync :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1348607516

From abimpoudis at openjdk.org  Fri Oct  6 11:58:38 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 6 Oct 2023 11:58:38 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v13]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add comment for TypePairs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/01ebecd9..f1a5e141

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=11-12

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From duke at openjdk.org  Fri Oct  6 12:33:44 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 6 Oct 2023 12:33:44 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v8]
In-Reply-To: 
References: 
 <9YOY2Anr1ITSCkpsfGt9UjMcceBvjYuFJhfC-lx-LuM=.64e11edb-b412-4385-bf75-604f155c7a1a@github.com>
 
Message-ID: 

On Wed, 27 Sep 2023 13:35:55 GMT, Roger Riggs  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce the size of HexFormat##DIGITS, from 256 to 128
>
> It is conventional to get re-reviews of any change and give the reviewers that taken the time to review the PR a chance to review any subsequent changes.

@RogerRiggs Can this PR be added to /sponsor now?

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1750574495

From redestad at openjdk.org  Fri Oct  6 14:23:04 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 6 Oct 2023 14:23:04 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 29 Sep 2023 20:03:09 GMT, ???  wrote:

>> In the improvement of @cl4es PR #15591, the advantages of non-lookup-table were discussed.
>> 
>> But if the input is byte[], using lookup table can improve performance.
>> 
>> For HexFormat#formatHex(Appendable, byte[]) and HexFormat#formatHex(byte[]), If the length of byte[] is larger, the performance of table lookup will be improved more obviously.
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

FWIW I'll not review or sponsor any PRs that use `ByteArrayLittleEndian` for trivial `byte[]` writes until there's been a thorough analysis of why this helps and shown that JITs can't be expected to generate code that is as optimal.

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1750762716

From sviswanathan at openjdk.org  Fri Oct  6 16:13:10 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 6 Oct 2023 16:13:10 GMT
Subject: RFR: 8314544: Matrix multiply benchmark using Vector API [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 6 Oct 2023 08:32:28 GMT, Martin Stypinski  wrote:

>> Martin Stypinski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - changed for consistency
>>  - improved some RandomGenerator & unuseed Imports
>
> fixed typo.

@Styp Thanks, the next step would be for you to flag this PR as ready for integration by typing /integrate in a new github comment and submit. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

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

PR Comment: https://git.openjdk.org/jdk/pull/15338#issuecomment-1751012629

From jvernee at openjdk.org  Fri Oct  6 16:12:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 6 Oct 2023 16:12:57 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v34]
In-Reply-To: 
References: 
Message-ID: 

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:

 - fix failing RestrictedMethods test
 - Merge branch 'master' into JEP22
 - Remove PIP annotation from jdk.incubator.vector
 - review @enablePreview from java/foreign/TestRestricted test
 - Merge branch 'master' into JEP22
 - drop unneeded @compile tags from jtreg tests
 - Use IAE instead of UOE for unsupported char sets
 - Use abort instead of IEA when encountering wrong value for ENA attrib.
 - Fix visibility issues
   
   Reviewed-by: mcimadamore
 - Review comments
 - ... and 53 more: https://git.openjdk.org/jdk/compare/b3cc0c84...b4a7b7ab

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

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=33
  Stats: 4361 lines in 263 files changed: 2211 ins; 1196 del; 954 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

PR: https://git.openjdk.org/jdk/pull/15103

From jvernee at openjdk.org  Fri Oct  6 16:13:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 6 Oct 2023 16:13:33 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v33]
In-Reply-To: <0r5bNt-ez79b7DrOJUuHCPguBQkn3MtEJdoQFqVuWxA=.86265508-9e7d-4fab-a851-35c5c138255d@github.com>
References: 
 <0r5bNt-ez79b7DrOJUuHCPguBQkn3MtEJdoQFqVuWxA=.86265508-9e7d-4fab-a851-35c5c138255d@github.com>
Message-ID: 

On Mon, 2 Oct 2023 16:07:09 GMT, Jorn Vernee  wrote:

>> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
>> 
>> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
>> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
>> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
>> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
>> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
>> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
>> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
>> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
>> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove PIP annotation from jdk.incubator.vector

I've addressed one more test failure in [b4a7b7a](https://github.com/openjdk/jdk/pull/15103/commits/b4a7b7abe75aee72c8e56c12c0ddbeb597e15f1b) that was found after merging this patch with the most recent master branch.

The test in questions checks for linter warnings for restricted methods. It depends on the FFM API for that, which is still preview in the master branch, but no longer preview as part of this patch. Hence the warnings the compiler outputs is different, and the test fails. I've fixed to test. The preview flags are no longer needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1751015355

From rgiulietti at openjdk.org  Fri Oct  6 16:26:42 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 6 Oct 2023 16:26:42 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v3]
In-Reply-To: 
References: 
Message-ID: 

> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Using compareUnsigned() rather than open logic.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16050/files
  - new: https://git.openjdk.org/jdk/pull/16050/files/bb4cc608..838d6f81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16050&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16050&range=01-02

  Stats: 8 lines in 2 files changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16050/head:pull/16050

PR: https://git.openjdk.org/jdk/pull/16050

From rgiulietti at openjdk.org  Fri Oct  6 16:26:43 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 6 Oct 2023 16:26:43 GMT
Subject: Integrated: 8317515: Unify the code of the parse*() families of
 methods in j.l.Integer and j.l.Long
In-Reply-To: 
References: 
Message-ID: 

On Thu, 5 Oct 2023 09:28:22 GMT, Raffaello Giulietti  wrote:

> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.

This pull request has now been integrated.

Changeset: b62e774e
Author:    Raffaello Giulietti 
URL:       https://git.openjdk.org/jdk/commit/b62e774e6a531db934de04211724a2a8159d94db
Stats:     456 lines in 2 files changed: 91 ins; 162 del; 203 mod

8317515: Unify the code of the parse*() families of methods in j.l.Integer and j.l.Long

Reviewed-by: redestad

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

PR: https://git.openjdk.org/jdk/pull/16050

From naoto at openjdk.org  Fri Oct  6 16:57:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Oct 2023 16:57:09 GMT
Subject: RFR: JDK-8317631: Refactor ChoiceFormat tests to use JUnit
In-Reply-To: 
References: 
Message-ID: 

On Thu, 5 Oct 2023 20:57:07 GMT, Justin Lu  wrote:

> Please review this PR which refactors the ChoiceFormat tests to use JUnit.

test/jdk/java/text/Format/ChoiceFormat/Bug8001209.java line 78:

> 76:                 "Mutating array returned from getter changed internals of ChoiceFormat");
> 77: 
> 78:         // Modify the array passed to setFormats() -> dayOfWeekNames

I think we should keep the `err` variable, and not throw an exception (and end the test) here. Otherwise, the test after this will not run.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16065#discussion_r1348978190

From duke at openjdk.org  Fri Oct  6 17:06:08 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 6 Oct 2023 17:06:08 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v10]
In-Reply-To: 
References: 
Message-ID: 

> In the improvement of @cl4es PR #15591, the advantages of non-lookup-table were discussed.
> 
> But if the input is byte[], using lookup table can improve performance.
> 
> For HexFormat#formatHex(Appendable, byte[]) and HexFormat#formatHex(byte[]), If the length of byte[] is larger, the performance of table lookup will be improved more obviously.

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

  Not ByteArrayLittleEndian

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15768/files
  - new: https://git.openjdk.org/jdk/pull/15768/files/1463863e..f7d832f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=08-09

  Stats: 17 lines in 1 file changed: 1 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/15768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15768/head:pull/15768

PR: https://git.openjdk.org/jdk/pull/15768

From mbalao at openjdk.org  Fri Oct  6 17:09:09 2023
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 6 Oct 2023 17:09:09 GMT
Subject: RFR: 8315487: Security Providers Filter
In-Reply-To: 
References: 
Message-ID: 

On Fri, 1 Sep 2023 15:13:46 GMT, Martin Balao  wrote:

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

I wish we could keep this PR open. This is the latest comment in the ongoing discussion: https://mail.openjdk.org/pipermail/security-dev/2023-October/037479.html

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

PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-1751120024

From duke at openjdk.org  Fri Oct  6 17:19:16 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 6 Oct 2023 17:19:16 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 6 Oct 2023 14:20:13 GMT, Claes Redestad  wrote:

> FWIW I'll not review or sponsor any PRs that use `ByteArrayLittleEndian` for trivial `byte[]` writes until there's been a thorough analysis of why this helps and shown that JITs can't be expected to generate code that is as optimal.

Thanks, I received your opinion and I have removed ByteArrayLittleEndian.

Such optimization should be done by JIT. It seems that this optimization is called SuperWord Level Parallelism (SLP). Currently, HotSpot C2 has only completed the loop version and not the linear version. Improvements require JIT experts to submit patches.

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1751137676

From jlu at openjdk.org  Fri Oct  6 17:25:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 17:25:36 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method
Message-ID: 

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 

That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.

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

Commit messages:
 - code tag for MessageFormat::applyPattenr as well
 - Review: use 'may' wording
 - init

Changes: https://git.openjdk.org/jdk/pull/16064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16064&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317612
  Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16064/head:pull/16064

PR: https://git.openjdk.org/jdk/pull/16064

From jlu at openjdk.org  Fri Oct  6 17:28:35 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 17:28:35 GMT
Subject: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader
Message-ID: 

Please review this PR which cleans up the static test utility class _HexDumpReader_.

This cleans up the code by replacing the nested _ByteArrayBuilder_ class with _HexFormat_, and simplifies the File processing by using a stream. Changes were tested to ensure that the _text_ tests are still getting equivalent ByteArrayInputStreams as before.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/16075/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16075&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317633
  Stats: 84 lines in 1 file changed: 12 ins; 62 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/16075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16075/head:pull/16075

PR: https://git.openjdk.org/jdk/pull/16075

From jlu at openjdk.org  Fri Oct  6 17:50:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 17:50:56 GMT
Subject: RFR: JDK-8317631: Refactor ChoiceFormat tests to use JUnit [v2]
In-Reply-To: 
References: 
Message-ID: <4F-M1i70U1KBTKWKbTEGCvIbPBaKZAKyLVFBHKHlqkU=.e766411d-a31e-481a-8f74-df25ceeee3d1@github.com>

> Please review this PR which refactors the ChoiceFormat tests to use JUnit.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: separate into two tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16065/files
  - new: https://git.openjdk.org/jdk/pull/16065/files/bd10afa8..fcd8ebfa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16065&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16065&range=00-01

  Stats: 40 lines in 1 file changed: 18 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/16065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16065/head:pull/16065

PR: https://git.openjdk.org/jdk/pull/16065

From jlu at openjdk.org  Fri Oct  6 17:50:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 17:50:59 GMT
Subject: RFR: JDK-8317631: Refactor ChoiceFormat tests to use JUnit [v2]
In-Reply-To: 
References: 
 
Message-ID: <8XWm3DvajZWJvGM3xh57V0lkssNtr8jUPhg15WqUpDY=.c7fff244-4b26-4bde-939c-775a05193ebf@github.com>

On Fri, 6 Oct 2023 16:54:03 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: separate into two tests
>
> test/jdk/java/text/Format/ChoiceFormat/Bug8001209.java line 78:
> 
>> 76:                 "Mutating array returned from getter changed internals of ChoiceFormat");
>> 77: 
>> 78:         // Modify the array passed to setFormats() -> dayOfWeekNames
> 
> I think we should keep the `err` variable, and not throw an exception (and end the test) here. Otherwise, the test after this will not run.

You're right, I should have actually split this larger test into two separate tests (one for the getter / one for the setter), then there would be no need for `err`.

I have updated the PR with the change I mentioned. Thank you for reviewing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16065#discussion_r1349144926

From jlu at openjdk.org  Fri Oct  6 18:07:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 18:07:37 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method [v2]
In-Reply-To: 
References: 
Message-ID: <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 
> 
> That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  tag setChoices as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16064/files
  - new: https://git.openjdk.org/jdk/pull/16064/files/b4c89dd4..dc9cbae6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16064&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16064&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16064/head:pull/16064

PR: https://git.openjdk.org/jdk/pull/16064

From kvn at openjdk.org  Fri Oct  6 18:31:31 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 6 Oct 2023 18:31:31 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - fix code style and formatting
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>  - change variable names of indexPivot* to pivotIndex*
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>  - Remove the unnecessary exception in single pivot partitioning fallback method
>  - Move functional interfaces close to the associated methods
>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>  - Refactor stub handling to use a generic function for all types
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86

My tier1-7 testing passed. Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14227#pullrequestreview-1662591699

From naoto at openjdk.org  Fri Oct  6 18:36:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Oct 2023 18:36:09 GMT
Subject: RFR: JDK-8317631: Refactor ChoiceFormat tests to use JUnit [v2]
In-Reply-To: <4F-M1i70U1KBTKWKbTEGCvIbPBaKZAKyLVFBHKHlqkU=.e766411d-a31e-481a-8f74-df25ceeee3d1@github.com>
References: 
 <4F-M1i70U1KBTKWKbTEGCvIbPBaKZAKyLVFBHKHlqkU=.e766411d-a31e-481a-8f74-df25ceeee3d1@github.com>
Message-ID: 

On Fri, 6 Oct 2023 17:50:56 GMT, Justin Lu  wrote:

>> Please review this PR which refactors the ChoiceFormat tests to use JUnit.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: separate into two tests

Good point dividing the test for granularity. Looks good

test/jdk/java/text/Format/ChoiceFormat/Bug8001209.java line 69:

> 67: 
> 68:     /*
> 69:      * Ensure that mutating he arrays returned by getChoices and getLimits does

Nit: typo "he"

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16065#pullrequestreview-1662596243
PR Review Comment: https://git.openjdk.org/jdk/pull/16065#discussion_r1349187144

From jlu at openjdk.org  Fri Oct  6 18:43:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 18:43:50 GMT
Subject: RFR: JDK-8317631: Refactor ChoiceFormat tests to use JUnit [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which refactors the ChoiceFormat tests to use JUnit.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review: comment typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16065/files
  - new: https://git.openjdk.org/jdk/pull/16065/files/fcd8ebfa..1bc3304c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16065&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16065&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16065.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16065/head:pull/16065

PR: https://git.openjdk.org/jdk/pull/16065

From duke at openjdk.org  Fri Oct  6 18:49:32 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 6 Oct 2023 18:49:32 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 6 Oct 2023 18:28:21 GMT, Vladimir Kozlov  wrote:

> My tier1-7 testing passed. Good.

Thank you, Vladimir!

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1751254526

From jlu at openjdk.org  Fri Oct  6 18:54:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 18:54:40 GMT
Subject: RFR: JDK-8317372: Refactor some NumberFormat tests to use JUnit
Message-ID: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>

Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.

During the switch to JUnit, the tests had the following updates (to improve readability)
- separate the test data generation from the actual execution of the test
- create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

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

Commit messages:
 - trailing ws
 - Clarify data provider for BigDecimalCompatibilityTest.java
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/16035/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317372
  Stats: 942 lines in 9 files changed: 389 ins; 200 del; 353 mod
  Patch: https://git.openjdk.org/jdk/pull/16035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16035/head:pull/16035

PR: https://git.openjdk.org/jdk/pull/16035

From lancea at openjdk.org  Fri Oct  6 19:04:08 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 6 Oct 2023 19:04:08 GMT
Subject: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 17:19:29 GMT, Justin Lu  wrote:

> Please review this PR which cleans up the static test utility class _HexDumpReader_.
> 
> This cleans up the code by replacing the nested _ByteArrayBuilder_ class with _HexFormat_, and simplifies the File processing by using a stream. Changes were tested to ensure that the _text_ tests are still getting equivalent ByteArrayInputStreams as before.

looks OK overall...

A couple minor comments below

test/jdk/java/text/testlib/HexDumpReader.java line 54:

> 52: 
> 53:     // Converts a Hex dump file (File) into an InputStream containing bytes
> 54:     public static InputStream getStreamFromHexDump(File hexFile) {

Maybe add a comment of the expected format of the file passed to this method.

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16075#pullrequestreview-1662633249
PR Review Comment: https://git.openjdk.org/jdk/pull/16075#discussion_r1349209871

From naoto at openjdk.org  Fri Oct  6 19:08:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Oct 2023 19:08:06 GMT
Subject: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 17:19:29 GMT, Justin Lu  wrote:

> Please review this PR which cleans up the static test utility class _HexDumpReader_.
> 
> This cleans up the code by replacing the nested _ByteArrayBuilder_ class with _HexFormat_, and simplifies the File processing by using a stream. Changes were tested to ensure that the _text_ tests are still getting equivalent ByteArrayInputStreams as before.

test/jdk/java/text/testlib/HexDumpReader.java line 60:

> 58:         } catch (IOException e) {
> 59:             throw new RuntimeException(String.format("Utility class HexDumpReader" +
> 60:                     " threw %s when trying to read the file %s", e, hexFile.getName()));

It's OK as it is. It could simply throw that `IOException` which may be simpler.

test/jdk/java/text/testlib/HexDumpReader.java line 65:

> 63:         String hexString = lines.stream().map(String::trim)
> 64:                 .map(s -> (s.contains("#")) ? s.substring(0, s.indexOf("#")).trim() : s)
> 65:                 .filter(s -> !s.isEmpty()).collect(Collectors.joining());

I think the common style is to wrap the line per each stream operation. Also, `trim()` can be done after removing `#` so that trimming is not necessary in that map operation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16075#discussion_r1349215609
PR Review Comment: https://git.openjdk.org/jdk/pull/16075#discussion_r1349210970

From lmesnik at openjdk.org  Fri Oct  6 19:32:31 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 6 Oct 2023 19:32:31 GMT
Subject: RFR: 8316464: 3 sun/tools tests ignore VM flags
Message-ID: 

I marked tests 
sun/tools/jcmd/TestProcessHelper.java
sun/tools/jinfo/JInfoTest.java
as headless. They used different specific VM options and are not worth executing with other VM flags. 
And fixed 
sun/tools/jstat/JStatInterval.java
Tested with tier1, local execution of tests, and running sun/tools/jstat/JStatInterval.java with different options.

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

Commit messages:
 - 8316464

Changes: https://git.openjdk.org/jdk/pull/16078/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16078&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316464
  Stats: 9 lines in 3 files changed: 3 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16078.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16078/head:pull/16078

PR: https://git.openjdk.org/jdk/pull/16078

From joehw at openjdk.org  Fri Oct  6 19:35:57 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 6 Oct 2023 19:35:57 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v2]
In-Reply-To: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
Message-ID: <4Gh1N9PvjyDWT_FC7AUUFFABLyJybgcNdeD5rSDHbYc=.ce1afde6-2c7f-4cdc-bfd4-8a21ba5ef4f1@github.com>

> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments, plus use URL for relative URI

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16045/files
  - new: https://git.openjdk.org/jdk/pull/16045/files/0248b82e..4f39bb96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=00-01

  Stats: 16 lines in 2 files changed: 4 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16045/head:pull/16045

PR: https://git.openjdk.org/jdk/pull/16045

From joehw at openjdk.org  Fri Oct  6 19:39:06 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 6 Oct 2023 19:39:06 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v2]
In-Reply-To: <4Gh1N9PvjyDWT_FC7AUUFFABLyJybgcNdeD5rSDHbYc=.ce1afde6-2c7f-4cdc-bfd4-8a21ba5ef4f1@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
 <4Gh1N9PvjyDWT_FC7AUUFFABLyJybgcNdeD5rSDHbYc=.ce1afde6-2c7f-4cdc-bfd4-8a21ba5ef4f1@github.com>
Message-ID: 

On Fri, 6 Oct 2023 19:35:57 GMT, Joe Wang  wrote:

>> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments, plus use URL for relative URI

Thanks Naoto. Addressing review comments. As we discussed offline, as we got CSR approval, we'll keep the javadoc in @param as a style choice. Added NPE for catalog; Fixed the redundant "returns"; Added error report. 
Furthermore, after consulting with Daniel, modified the Util method with URL instead of URI/Path as the former is a more straight-forward solution requiring no additional manipulation.

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

PR Comment: https://git.openjdk.org/jdk/pull/16045#issuecomment-1751316026

From lmesnik at openjdk.org  Fri Oct  6 20:05:19 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 6 Oct 2023 20:05:19 GMT
Subject: RFR: 8316452:
 java/lang/instrument/modules/AppendToClassPathModuleTest.java ignores VM flags
Message-ID: 

The test uses specific classpath, and jar and is intended to test modules. So I marked is as flagless,

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

Commit messages:
 - 8316452

Changes: https://git.openjdk.org/jdk/pull/16080/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16080&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316452
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16080.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16080/head:pull/16080

PR: https://git.openjdk.org/jdk/pull/16080

From duke at openjdk.org  Fri Oct  6 20:18:39 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 6 Oct 2023 20:18:39 GMT
Subject: Integrated: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 May 2023 18:54:50 GMT, Srinivas Vamsi Parasa  wrote:

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
> 
> 
> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
> 
> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
> |	---	|	---	|	---	|	---	|	---	|
> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
> |	ArraysSort.longSort	|	1000	|	10.449	|	6.239	|	1.7	|
> |	ArraysSort.longSort	|	10000	|	307.074	|	70.284	|	**4.4**	|
> |	ArraysSor...

This pull request has now been integrated.

Changeset: a4e9168b
Author:    vamsi-parasa 
Committer: Sandhya Viswanathan 
URL:       https://git.openjdk.org/jdk/commit/a4e9168bab1c2872ce2dbc7971a45c259270271f
Stats:     3410 lines in 22 files changed: 2902 ins; 292 del; 216 mod

8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays)

Reviewed-by: jbhateja, sviswanathan, psandoz, kvn

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

PR: https://git.openjdk.org/jdk/pull/14227

From naoto at openjdk.org  Fri Oct  6 20:58:07 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Oct 2023 20:58:07 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v2]
In-Reply-To: <4Gh1N9PvjyDWT_FC7AUUFFABLyJybgcNdeD5rSDHbYc=.ce1afde6-2c7f-4cdc-bfd4-8a21ba5ef4f1@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
 <4Gh1N9PvjyDWT_FC7AUUFFABLyJybgcNdeD5rSDHbYc=.ce1afde6-2c7f-4cdc-bfd4-8a21ba5ef4f1@github.com>
Message-ID: 

On Fri, 6 Oct 2023 19:35:57 GMT, Joe Wang  wrote:

>> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments, plus use URL for relative URI

test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogTest.java line 509:

> 507:     @Test(expectedExceptions = NullPointerException.class)
> 508:     public void testFeatureNull() {
> 509:         CatalogResolver resolver = CatalogManager.catalogResolver((CatalogFeatures)null, (URI)null);

I misunderstood this change, as I thought this was for testing `null` for the *new* method. Should we have the equivalent one for the new method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16045#discussion_r1349313557

From jlu at openjdk.org  Fri Oct  6 21:07:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 21:07:51 GMT
Subject: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which cleans up the static test utility class _HexDumpReader_.
> 
> This cleans up the code by replacing the nested _ByteArrayBuilder_ class with _HexFormat_, and simplifies the File processing by using a stream. Changes were tested to ensure that the _text_ tests are still getting equivalent ByteArrayInputStreams as before.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Reflect review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16075/files
  - new: https://git.openjdk.org/jdk/pull/16075/files/498b9096..6081b208

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16075&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16075&range=00-01

  Stats: 28 lines in 1 file changed: 10 ins; 6 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/16075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16075/head:pull/16075

PR: https://git.openjdk.org/jdk/pull/16075

From jlu at openjdk.org  Fri Oct  6 21:07:55 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 21:07:55 GMT
Subject: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 18:57:36 GMT, Lance Andersen  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect review comments
>
> test/jdk/java/text/testlib/HexDumpReader.java line 54:
> 
>> 52: 
>> 53:     // Converts a Hex dump file (File) into an InputStream containing bytes
>> 54:     public static InputStream getStreamFromHexDump(File hexFile) {
> 
> Maybe add a comment of the expected format of the file passed to this method.

Thanks for the review. Updated the documentation to describe the format that the hex dump file should be in, and examples.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16075#discussion_r1349317616

From jlu at openjdk.org  Fri Oct  6 21:07:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 21:07:59 GMT
Subject: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 18:58:56 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect review comments
>
> test/jdk/java/text/testlib/HexDumpReader.java line 65:
> 
>> 63:         String hexString = lines.stream().map(String::trim)
>> 64:                 .map(s -> (s.contains("#")) ? s.substring(0, s.indexOf("#")).trim() : s)
>> 65:                 .filter(s -> !s.isEmpty()).collect(Collectors.joining());
> 
> I think the common style is to wrap the line per each stream operation. Also, `trim()` can be done after removing `#` so that trimming is not necessary in that map operation.

Thanks for the review. Talked with Lance offline, and since none of the existing dump files actually use a non-leading comment, I changed the stream to only look for leading comments (removed ternary map operation).

As a result, I adjusted the documentation to state that a valid valid hex dump file format does not allow non-leading comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16075#discussion_r1349317598

From duke at openjdk.org  Fri Oct  6 21:08:38 2023
From: duke at openjdk.org (iaroslavski)
Date: Fri, 6 Oct 2023 21:08:38 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 
 
Message-ID: <4ED7o2x_n_tasfC5KfpkB2K9bpVfyl_-mNTNas92Suk=.4744bf9a-e1d0-43ec-9305-5c1c0238e952@github.com>

On Fri, 6 Oct 2023 18:45:59 GMT, Srinivas Vamsi Parasa  wrote:

>> My tier1-7 testing passed. Good.
>
>> My tier1-7 testing passed. Good.
> 
> Thank you, Vladimir!

Hi @vamsi-parasa,

May be too late but there is one question. We have 2 new methods
`private static  void sort(Class elemType, A array, ...`
`private static  int[] partition(Class elemType, A array, ...`
and 4 methods which are passed to them:
`mixedInsertionSort, insertionSort, partitionDualPivot, partitionDualPivot`

Methods `partitionDualPivot` and `partitionDualPivot`are `@ForceInline`,
but `mixedInsertionSort' and `insertionSort` are not. Is it ok, or we missed something?

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1751401463

From vlv.spb.ru at mail.ru  Fri Oct  6 21:45:00 2023
From: vlv.spb.ru at mail.ru (=?UTF-8?B?VmxhZGltaXIgWWFyb3NsYXZza2l5?=)
Date: Sat, 07 Oct 2023 00:45:00 +0300
Subject: =?UTF-8?B?ODMwOTEzMDogeDg2XzY0IEFWWDUxMiBpbnRyaW5zaWNzIGZvciBBcnJheXMu?=
 =?UTF-8?B?c29ydCBtZXRob2RzIChpbnQsIGxvbmcsIGZsb2F0IGFuZCBkb3VibGUgYXJy?=
 =?UTF-8?B?YXlzKQ==?=
In-Reply-To: 
References: 
Message-ID: <1696628700.868157594@f342.i.mail.ru>


Hi ?Vamsi
May be too late but there is one question. We have 2 new methods
private static  void sort(Class elemType, A array, ...
private static  int[] partition(Class elemType, A array, ...
and 4 methods which are passed to them:
mixedInsertionSort, insertionSort, partitionDualPivot, partitionDualPivot
Methods ? partitionDualPivot ? and ? partitionDualPivot are ? @ForceInline ,
but ? mixedInsertionSort' and  insertionSort` are not. Is it ok, or we missed something?
PR? https://github.com/openjdk/jdk/pull/14227
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From naoto at openjdk.org  Fri Oct  6 21:47:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Oct 2023 21:47:25 GMT
Subject: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 21:07:51 GMT, Justin Lu  wrote:

>> Please review this PR which cleans up the static test utility class _HexDumpReader_.
>> 
>> This cleans up the code by replacing the nested _ByteArrayBuilder_ class with _HexFormat_, and simplifies the File processing by using a stream. Changes were tested to ensure that the _text_ tests are still getting equivalent ByteArrayInputStreams as before.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comments

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16075#pullrequestreview-1662833379

From almatvee at openjdk.org  Fri Oct  6 23:31:37 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 6 Oct 2023 23:31:37 GMT
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild
Message-ID: 

- Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
- If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
> Error: "codesign" failed with following output:
> test: no identity found

> Error: "productbuild" failed with following output:
> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
- Added error handling not to allow invalid combinations of signing options.
- Updated signing tests to test new changes.

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

Commit messages:
 - 8311877: [macos] Add CLI options to provide signing identity directly to codesign and productbuild

Changes: https://git.openjdk.org/jdk/pull/16085/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16085&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311877
  Stats: 550 lines in 24 files changed: 463 ins; 23 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/16085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16085/head:pull/16085

PR: https://git.openjdk.org/jdk/pull/16085

From joehw at openjdk.org  Fri Oct  6 23:36:14 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 6 Oct 2023 23:36:14 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v3]
In-Reply-To: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
Message-ID: <1HvD4945vZomMMgZcSG2YrHIyYmnX_ZrMxBYj1wKpRY=.a92ba55b-904c-42cb-91e5-2f884c0d3879@github.com>

> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add a test for the NPE case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16045/files
  - new: https://git.openjdk.org/jdk/pull/16045/files/4f39bb96..f1d726ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=01-02

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16045/head:pull/16045

PR: https://git.openjdk.org/jdk/pull/16045

From joehw at openjdk.org  Fri Oct  6 23:36:17 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 6 Oct 2023 23:36:17 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v2]
In-Reply-To: 
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
 <4Gh1N9PvjyDWT_FC7AUUFFABLyJybgcNdeD5rSDHbYc=.ce1afde6-2c7f-4cdc-bfd4-8a21ba5ef4f1@github.com>
 
Message-ID: <9y6udMKzaHtZ-siHxVwyOVs76SImUNOINwfJQB5m9Ok=.98efd403-0366-4e03-bafd-9bf8b944bba8@github.com>

On Fri, 6 Oct 2023 20:54:34 GMT, Naoto Sato  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments, plus use URL for relative URI
>
> test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogTest.java line 509:
> 
>> 507:     @Test(expectedExceptions = NullPointerException.class)
>> 508:     public void testFeatureNull() {
>> 509:         CatalogResolver resolver = CatalogManager.catalogResolver((CatalogFeatures)null, (URI)null);
> 
> I misunderstood this change, as I thought this was for testing `null` for the *new* method. Should we have the equivalent one for the new method?

True, added a test. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16045#discussion_r1349365622

From naoto at openjdk.org  Fri Oct  6 23:36:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Oct 2023 23:36:15 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v3]
In-Reply-To: <1HvD4945vZomMMgZcSG2YrHIyYmnX_ZrMxBYj1wKpRY=.a92ba55b-904c-42cb-91e5-2f884c0d3879@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
 <1HvD4945vZomMMgZcSG2YrHIyYmnX_ZrMxBYj1wKpRY=.a92ba55b-904c-42cb-91e5-2f884c0d3879@github.com>
Message-ID: 

On Fri, 6 Oct 2023 22:48:40 GMT, Joe Wang  wrote:

>> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add a test for the NPE case

Looks good. Thanks for making the changes

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16045#pullrequestreview-1662882822

From mik3hall at gmail.com  Sat Oct  7 00:50:42 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 6 Oct 2023 19:50:42 -0500
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild
In-Reply-To: 
References: 
Message-ID: 



> On Oct 6, 2023, at 6:31 PM, Alexander Matveev  wrote:
> 
> CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).

> We will not do any validations of certificates in this case like we do with --mac-signing-key-user-name or we will not check if produced application image or installer got signed correctly. 

Again, a suggestion might be to do a codesign verify. For example?

codesign -v --verbose=4 outputdir/HalfPipe.app

man codesign
-v, --verify
             Requests verification of code signatures.  If other actions (sign, display, etc.) are also requested, -v is interpreted to mean --verbose.

Doing this might allow to fail if errors are indicated or at least provide information maybe on verbose runs if there seem to be problems.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sat Oct  7 01:51:14 2023
From: duke at openjdk.org (yaqsun)
Date: Sat, 7 Oct 2023 01:51:14 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java fails
 on CentOS Linux release 8.5.2111 and Fedora 27
Message-ID: 

on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.

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

Commit messages:
 - fixed Whitespace error: del tab
 - 8316563: test tools/jpackage/linux/LinuxResourceTest.java fails on RHEL8 and Fedora 27

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

PR: https://git.openjdk.org/jdk/pull/15832

From jpai at openjdk.org  Sat Oct  7 01:51:14 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 7 Oct 2023 01:51:14 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 03:32:55 GMT, yaqsun  wrote:

> on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
> It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
> But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.

Hello @yaqsun, for this PR to trigger the official review process, the title of this PR should match the JBS title. Can you update the PR title to `8316563: test tools/jpackage/linux/LinuxResourceTest.java fails on CentOS Linux release 8.5.2111 and Fedora 27`

Hello @yaqsun, thank you for fixing the title of this PR. It appears that additionally you have to fix some issues in the proposed code (tab usages) before this PR can generate a review request. Please take a look at the jcheck failure listed in the GitHub actions job of this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/15832#issuecomment-1737226863
PR Comment: https://git.openjdk.org/jdk/pull/15832#issuecomment-1744791624

From duke at openjdk.org  Sat Oct  7 11:50:43 2023
From: duke at openjdk.org (Lukas Bergdoll)
Date: Sat, 7 Oct 2023 11:50:43 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
Message-ID: <8jhnXoy8assyBe6W2aPXeBAIvkxrwUBTtqoa44zIjd0=.e5ba23a1-523b-457d-ab8c-fc17040e565d@github.com>

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - fix code style and formatting
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>  - change variable names of indexPivot* to pivotIndex*
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>  - Remove the unnecessary exception in single pivot partitioning fallback method
>  - Move functional interfaces close to the associated methods
>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>  - Refactor stub handling to use a generic function for all types
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86

When the numpy news came out I analyzed the intel implementation here https://github.com/Voultapher/sort-research-rs/blob/main/writeup/intel_avx512/text.md. I think it's relevant here as well. I assume the new version of x86-simd-sort contains improvements, I hope they have addressed the easy to hit quadratic runtime.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1751690502

From javalists at cbfiddle.com  Sat Oct  7 12:59:54 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sat, 7 Oct 2023 05:59:54 -0700
Subject: Metal renderer threading issues [macOS]
Message-ID: <0DCC2CCE-F246-42F0-8D07-3D2D50C33D7B@cbfiddle.com>

I?ve been investigating a problem with a long running application that accumulates an apparently unbounded number of
CVDisplayLink threads. I do not yet have an explanation or a test case.

The code that creates and releases CVDisplayLinks looks fine, but that assumes there are no threading issues.
It looks like there are threading issues.

Specifically, it appears that the startDisplayLink and stopDisplayLink methods of the Objective-C class MTLLayer are invoked on multiple threads.

They are invoked on the AppKit main thread from screen sleep notifications and blitTexture.

They are invoked on the EDT from MTLLayer.validate.

They are invoked on the Queue Flusher thread from MTLRenderQueue.flushBuffer.

Perhaps someone familiar with this code could comment?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From fw at deneb.enyo.de  Sat Oct  7 13:25:19 2023
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 07 Oct 2023 15:25:19 +0200
Subject: Integrated: 8309130: x86_64 AVX512 intrinsics for Arrays.sort
 methods (int, long, float and double arrays)
In-Reply-To: 
 (Srinivas Vamsi Parasa's message of "Fri, 6 Oct 2023 20:18:39 GMT")
References: 
 
Message-ID: <87mswuy37k.fsf@mid.deneb.enyo.de>

I believe this has introduced a build failure with GCC 12.2 on Debian 12.1:

Building target 'jdk' in configuration '/home/fw/build/jdk'
In file included from /usr/lib/gcc/x86_64-linux-gnu/12/include/immintrin.h:49,
                 from ?/jdk/src/java.base/linux/native/libsimdsort/avx512-common-qsort.h:60,
                 from ?/jdk/src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp:31,
                 from ?/jdk/src/java.base/linux/native/libsimdsort/avx512-linux-qsort.cpp:26:
In function '__m512i _mm512_shuffle_epi32(__m512i, _MM_PERM_ENUM)',
    inlined from 'static zmm_vector::zmm_t zmm_vector::shuffle(zmm_t) [with unsigned char mask = 177]' at ?/jdk/src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp:96:36,
    inlined from 'zmm_t sort_zmm_32bit(zmm_t) [with vtype = zmm_vector; zmm_t = __vector(8) long long int]' at ?/jdk/src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp:170:27:
/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512fintrin.h:4459:50: error: '__Y' is used uninitialized [-Werror=uninitialized]
 4459 |   return (__m512i) __builtin_ia32_pshufd512_mask ((__v16si) __A,
      |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
 4460 |                                                   __mask,
      |                                                   ~~~~~~~
 4461 |                                                   (__v16si)
      |                                                   ~~~~~~~~~
 4462 |                                                   _mm512_undefined_epi32 (),
      |                                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~
 4463 |                                                   (__mmask16) -1);
      |                                                   ~~~~~~~~~~~~~~~
/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512fintrin.h: In function 'zmm_t sort_zmm_32bit(zmm_t) [with vtype = zmm_vector; zmm_t = __vector(8) long long int]':
/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512fintrin.h:206:11: note: '__Y' was declared here
  206 |   __m512i __Y = __Y;
      |           ^~~

From dl at openjdk.org  Sat Oct  7 13:45:55 2023
From: dl at openjdk.org (Doug Lea)
Date: Sat, 7 Oct 2023 13:45:55 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v47]
In-Reply-To: 
References: 
Message-ID: 

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  better window encoding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/01e31edd..eb0f8dc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=45-46

  Stats: 36 lines in 1 file changed: 4 ins; 6 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From duke at openjdk.org  Sat Oct  7 15:36:42 2023
From: duke at openjdk.org (iaroslavski)
Date: Sat, 7 Oct 2023 15:36:42 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 
 
Message-ID: <3TYr-OTpr2mnSKZWGH5GaQPCwRfqQNALZIFBgaTWseo=.2216a003-6d84-484d-bd00-786d7f4d2de5@github.com>

On Fri, 6 Oct 2023 18:45:59 GMT, Srinivas Vamsi Parasa  wrote:

>> My tier1-7 testing passed. Good.
>
>> My tier1-7 testing passed. Good.
> 
> Thank you, Vladimir!

Hi @vamsi-parasa,

If DualPivotQuicksort.java is updated, can you improve `partitionDualPivot` and `partitionSinglePivot` methods a little bit also?

We pass `int high` there and then assign `int end = high - 1;`, but later `high` is never used.
It will be better to pass `end` instead of `high`, eliminate `int end = high - 1;` and don't introduce new variable.
This is minor changes but sorting shows better performance.

Please find my suggested code:

1. Replace high -> end, update javadoc: exclusive -> inclusive

` * @param end the index of the last element, inclusive, to be sorted`
` */`
`int[] partition(A a, int low, int end, ...`

` * @param end the index of the last element, inclusive, to be sorted`
` */`
`@IntrinsicCandidate`
`@ForceInline`
`private static  int[] partition(Class elemType, A array, long offset, int low, int end, ...`
`    return po.partition(array, low, end, pivotIndex1, pivotIndex2);`
`}`

`private static int[] partitionDualPivot(int[] a, int low, int end,`
`   int lower = low;`
`   int upper = end;`

`private static int[] partitionSinglePivot(int[] a, int low, int end,`
`   int lower = low;`
`   int upper = end;`

2. Javadoc of `int[] partition(A a, int low, )` says 'to be sorted' for paramters a, low and high.
It should be `to be partitioned`. Please correct.

3. The same for method `private static  int[] partition(Class elemType,`, update javadoc.

4. Changes from Item 1. require correspondent changes in C++ sources, could please take care of it?

5. And changes from my previous comment: all 4 methods should have @ForceInline and all methods should be without
@ForceInline. Am I right?

I guess new PR should be opened for all mentioned changes. Could you please go ahead?
I appreciate if you help to make sorting more accurate and better.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1751739561

From dl at openjdk.org  Sat Oct  7 17:56:27 2023
From: dl at openjdk.org (Doug Lea)
Date: Sat, 7 Oct 2023 17:56:27 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v48]
In-Reply-To: 
References: 
Message-ID: <_Dk4eLS84kKcEJXJroO8Zqc3sBVKJMhvP2CeWOdXekc=.661d71d1-1486-42d3-acde-1a2e87a9e4c9@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

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

 - Merge branch 'openjdk:master' into JDK-8288899
 - better window encoding
 - Merge branch 'openjdk:master' into JDK-8288899
 - cleanup
 - Merge branch 'openjdk:master' into JDK-8288899
 - refactor termination
 - Undo stray edit
 - Streamline push; add redundant interrupts
 - Merge branch 'openjdk:master' into JDK-8288899
 - Possibly re-interrupt when stopping
 - ... and 86 more: https://git.openjdk.org/jdk/compare/02ba18c7...5f40a9d2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/eb0f8dc6..5f40a9d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=46-47

  Stats: 11808 lines in 304 files changed: 6267 ins; 2225 del; 3316 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From mli at openjdk.org  Sat Oct  7 20:00:16 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sat, 7 Oct 2023 20:00:16 GMT
Subject: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader [v2]
In-Reply-To: 
References: 
 
Message-ID: <2DeXdkxg7TO-PfsVR2jptEzSG_YZ3PwbZvxOj1bTqYc=.cfb45c74-593f-4476-ad8f-fe3af7ce7996@github.com>

On Fri, 6 Oct 2023 21:07:51 GMT, Justin Lu  wrote:

>> Please review this PR which cleans up the static test utility class _HexDumpReader_.
>> 
>> This cleans up the code by replacing the nested _ByteArrayBuilder_ class with _HexFormat_, and simplifies the File processing by using a stream. Changes were tested to ensure that the _text_ tests are still getting equivalent ByteArrayInputStreams as before.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comments

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16075#pullrequestreview-1663103920

From mli at openjdk.org  Sat Oct  7 20:06:14 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sat, 7 Oct 2023 20:06:14 GMT
Subject: RFR: 8317471: ListFormat::parseObject() spec can be improved on
 parsePosition valid values
In-Reply-To: 
References: 
Message-ID: 

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato  wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16063#pullrequestreview-1663104345

From duke at openjdk.org  Sat Oct  7 21:51:39 2023
From: duke at openjdk.org (iaroslavski)
Date: Sat, 7 Oct 2023 21:51:39 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 6 Oct 2023 18:45:59 GMT, Srinivas Vamsi Parasa  wrote:

>> My tier1-7 testing passed. Good.
>
>> My tier1-7 testing passed. Good.
> 
> Thank you, Vladimir!

@vamsi-parasa
Please disrard my request to change high -> end. I find out a way to update Java code only.
I updated my previous comment. Only items 2, 3, 5 should be performed.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1751825424

From Alan.Bateman at oracle.com  Sun Oct  8 05:31:42 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 8 Oct 2023 06:31:42 +0100
Subject: Metal renderer threading issues [macOS]
In-Reply-To: <0DCC2CCE-F246-42F0-8D07-3D2D50C33D7B@cbfiddle.com>
References: <0DCC2CCE-F246-42F0-8D07-3D2D50C33D7B@cbfiddle.com>
Message-ID: <7a94dff0-0a70-4e54-c4fc-161db113d53b@oracle.com>

On 07/10/2023 13:59, Alan Snyder wrote:
> I?ve been investigating a problem with a long running application that 
> accumulates an apparently unbounded number of
> CVDisplayLink threads. I do not yet have an explanation or a test case.
>
> The code that creates and releases CVDisplayLinks looks fine, but that 
> assumes there are no threading issues.
> It looks like there are threading issues.
>
> Specifically, it appears that the startDisplayLink and stopDisplayLink 
> methods of?the Objective-C class MTLLayer are invoked on multiple threads.
>
> They are invoked on the AppKit main thread from screen sleep 
> notifications and blitTexture.
>
> They are invoked on the EDT from MTLLayer.validate.
>
> They are invoked on the Queue Flusher thread 
> from?MTLRenderQueue.flushBuffer.
>
> Perhaps someone familiar with this code could comment?
>
It would be better to being this to client-lib-dev as that is where the 
metal pipeline is maintained.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sun Oct  8 06:21:45 2023
From: duke at openjdk.org (Danny Thomas)
Date: Sun, 8 Oct 2023 06:21:45 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
Message-ID: <6IgF8wcto7s8tj_yB733vzEUB_3f1pmJVXqKsMeoQ2w=.9b008a1a-aaed-4879-b8a0-6ef41fc87a08@github.com>

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - fix code style and formatting
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>  - change variable names of indexPivot* to pivotIndex*
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>  - Remove the unnecessary exception in single pivot partitioning fallback method
>  - Move functional interfaces close to the associated methods
>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>  - Refactor stub handling to use a generic function for all types
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86

A [discussion on Reddit](https://www.reddit.com/r/java/comments/171t5sj/heads_up_openjdk_implementation_of_avx512_based/) raised that this had the potential to regress sort performance on AMD Zen 4. The poster didn't have access to Zen 4 hardware, so I took a moment to run the benchmark, comparing against a baseline with `UseAVX=2` on an AWS `m7a.4xlarge`:


processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 25
model		: 17
model name	: AMD EPYC 9R14
stepping	: 1
microcode	: 0xa10113e
cpu MHz		: 3673.537
cache size	: 1024 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 8
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 16
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf tsc_known_freq pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch topoext perfctr_core invpcid_single ssbd perfmon_v2 ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx512_bf16 clzero xsaveerptr rdpru wbnoinvd arat avx512vbmi pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid flush_l1d
bugs		: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips	: 5200.00
TLB size	: 3584 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management:



$ make test TEST="micro:java.lang.ArraysSort.intSort"

Benchmark            (size)  Mode  Cnt      Score     Error  Units
ArraysSort.intSort       10  avgt    3      0.033 ?   0.001  us/op
ArraysSort.intSort       25  avgt    3      0.067 ?   0.002  us/op
ArraysSort.intSort       50  avgt    3      0.391 ?   0.007  us/op
ArraysSort.intSort       75  avgt    3      0.923 ?   0.041  us/op
ArraysSort.intSort      100  avgt    3      1.292 ?   0.009  us/op
ArraysSort.intSort     1000  avgt    3     24.268 ?   0.078  us/op
ArraysSort.intSort    10000  avgt    3    320.131 ?   0.381  us/op
ArraysSort.intSort   100000  avgt    3   4803.142 ?  63.901  us/op
ArraysSort.intSort  1000000  avgt    3  61457.708 ? 347.446  us/op



$ make test TEST="micro:java.lang.ArraysSort.intSort" MICRO="VM_OPTIONS=-XX:UseAVX=2"

Benchmark            (size)  Mode  Cnt      Score      Error  Units
ArraysSort.intSort       10  avgt    3      0.034 ?    0.001  us/op
ArraysSort.intSort       25  avgt    3      0.091 ?    0.008  us/op
ArraysSort.intSort       50  avgt    3      0.247 ?    0.022  us/op
ArraysSort.intSort       75  avgt    3      0.432 ?    0.005  us/op
ArraysSort.intSort      100  avgt    3      0.560 ?    0.018  us/op
ArraysSort.intSort     1000  avgt    3      8.848 ?    0.530  us/op
ArraysSort.intSort    10000  avgt    3    118.476 ?  478.914  us/op
ArraysSort.intSort   100000  avgt    3   4656.937 ?  110.323  us/op
ArraysSort.intSort  1000000  avgt    3  56598.595 ? 2749.859  us/op


This is explained in the linked comments/commits:

- https://github.com/intel/x86-simd-sort/issues/6#issuecomment-1433687405
- https://github.com/natmaurice/x86-simd-sort/commit/41d03b2d8f3b62a2ee6a3a97a8da7f193a407026

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1751934240

From shaojin.wensj at alibaba-inc.com  Sun Oct  8 06:52:13 2023
From: shaojin.wensj at alibaba-inc.com (=?UTF-8?B?5rip57uN6ZSmKOmrmOmTgSk=?=)
Date: Sun, 08 Oct 2023 14:52:13 +0800
Subject: =?UTF-8?B?U2hvdWxkIHdlIGFsbG93IHVzZSBVbnNhZmUgb3IgQnl0ZUFycmF5TGl0dGxlRW5kaWFuIGZv?=
 =?UTF-8?B?ciB0cml2aWFsIGJ5dGVbXSB3cml0ZXMgaW4gY29yZS1saWJz77yf?=
Message-ID: <8561ed7c-6afc-4d16-ad71-b896f22e178d.shaojin.wensj@alibaba-inc.com>

Should we allow use Unsafe or ByteArrayLittleEndian for trivial byte[] writes in core-libs?
There is already code that uses ByteArrayLittleEndian to improve performance, such as:
```java
package java.util;
class UUID {
public String toString() {
// ...
 ByteArrayLittleEndian.setInt(
 buf,
 9,
 HexDigits.packDigits(((int) msb) >> 24, ((int) msb) >> 16));
 // ...
}
}
```
There are examples of using ByteArrayLittleEndian and then removing it because it caused the JVM to start slowly (we can use Unsafe.putShortUnaligned to solve the problem of slow JVM startup)
```java
package java.lang;
class StringLatin1 {
 private static void writeDigitPair(byte[] buf, int charPos, int value) {
 short pair = DecimalDigits.digitPair(value);
 // UNSAFE.putShortUnaligned(buf, ARRAY_BYTE_BASE_OFFSET + charPos, pair);
 buf[charPos] = (byte)(pair);
 buf[charPos + 1] = (byte)(pair >> 8);
 } 
}
```
Here is an example in the PR Review is disagreeing with the use of ByteArrayLittleEndian
https://github.com/openjdk/jdk/pull/15768 
```java
package java.util;
class HexFormat {
String formatOptDelimiter(byte[] bytes, int fromIndex, int toIndex) {
 // ...
 short pair = HexDigits.digitPair(bytes[fromIndex + i], ucase);
 int pos = i * 2;
 rep[pos] = (byte)pair;
 rep[pos + 1] = (byte)(pair >>> 8);
 // ByteArrayLittleEndian.setShort(rep, pos, pair);
}
}
```
This is another example of PR Review disagreeing with the use of ByteArrayLittleEndian.
https://github.com/openjdk/jdk/pull/15990 
```java
package java.lang;
class AbstractStringBuilder {
static final class Constants {
 static final int NULL_LATIN1;
 static final int NULL_UTF16;
 static {
 byte[] bytes4 = new byte[] {'t', 'r', 'u', 'e'};
 byte[] bytes8 = new byte[8];
 NULL_LATIN1 = ByteArrayLittleEndian.getInt(bytes4, 0);
 StringLatin1.inflate(bytes4, 0, bytes8, 0, 4);
 NULL_UTF16 = ByteArrayLittleEndian.getLong(bytes8, 0);
 }
 }
 private AbstractStringBuilder appendNull() {
 ensureCapacityInternal(count + 4);
 int count = this.count;
 byte[] val = this.value;
 if (isLatin1()) {
 ByteArrayLittleEndian.setInt(val, count, Constants.NULL_LATIN1);
 } else {
 ByteArrayLittleEndian.setLong(val, count << 1, Constants.NULL_UTF16);
 }
 this.count = count + 4;
 return this;
 }
}
```
In these examples, using Unsafe/ByteArrayLittleEndian significantly improves performance. If JIT automatic optimization is the best solution, but SuperWord Level Parallelism (SLP) does not currently support this optimization, what are our recommendations? What scenarios cannot use Unsafe, and what scenarios cannot use ByteArrayLittleEndian?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jens at lidestrom.se  Sun Oct  8 10:16:05 2023
From: jens at lidestrom.se (=?UTF-8?Q?Jens_Lidestr=C3=B6m?=)
Date: Sun, 08 Oct 2023 12:16:05 +0200
Subject: Library additions for shell scripting
Message-ID: 

Hello, Core lib developers :)

Java is pretty decent for shell scripts style programs now days!

I'd like to suggest a couple of additions to the standard library to 
make it better.

## Background

By "shell script style programs" I mean programs that don't have a GUI 
and mostly perform these tasks: Move files around, read and write files, 
executes commands, execute external programs and fetch network files.

Simple shell scripts are often written in Bash or Batch. Slightly more 
complex scripts are often written in for example Python.

For an organisation that works mostly with Java it's an advantage to be 
able to instead use Java for these slightly complex scripts, so that 
developers can use their existing Java skills instead of learning an 
alternative language.

Historically Java has been a rather poor choice for shell scripts, 
because of need for a separate compile step, and the verbosity of the 
language and the relevant libraries.

Now days Java is have become reasonable choice, after the following 
additions:

* New file API based on Path and Files in Java 7.
* Addition and improvement of ProcessBuilder in Java 5-9.
* Addition of java.net.http.HttpClient in Java 11.
* Ability to run single file programs without a separate compilation 
step in Java 11.
* Features to write more succinct code, such as collections factories 
and records.

However: A few common tasks are still hard or unnecessary fiddly. Many 
of these tasks can be performed with external libraries such as Guava or 
Apache Commons, but for shell script style programs it's hard to include 
external libraries.

I think this could be helped by a few relatively minor additions to the 
standard library.

## Tasks that would benefit from improvements

Ordered approximately according to how important I think they are.

### 1. Wait for termination of an external process and get its output

* Wait for the termination of an external process, with a timeout, and 
then capturing its output as a string.

* The best current solution I have been able find is to use a Future to 
wait for the output.

* Example solution: 
https://stackoverflow.com/questions/41491327/how-to-get-the-output-from-a-process-and-set-a-timeout/73486466#73486466

* This can probably be fixed by some addition to ProcessBuilder.

### 2. Recursively delete a directory

* Recursively delete a directory, including its files and nested 
directories.

* The best current solution I have been able find: 
https://www.baeldung.com/java-delete-directory

### 3. Pack and unpack a zip file

* Create a zip file with the arbitrary contents of a directory, 
including nested directories.

* Unpack a full zip file including all files and nested sub-directories, 
then write it to disk.

* The best current solution I have been able find involves manually 
looping over all files or zip entries: 
https://www.baeldung.com/java-compress-and-uncompress#unzip

* This can often a done by calling an external command, but a pure Java 
solution would be better.

### 4. Report download process in HttpClient

* Some way to report how much of a large file that has been downloaded 
using HttpClient.

* A very minor improvement.

* The best current solution I have been able find involves creating a 
custom BodyHandler: https://stackoverflow.com/a/77250200/452775

### 5. List directory contents eagerly

* Currently there is `Files#list`, but the returned steam needs to be 
closed using a try-with-resources.

* This is minor but re-occurring annoyance. An eager version of this 
method would be a quality-of-life improvement.

* Guava has `MoreFiles#listFiles` for this.


### 6. Parse and generate JSON

* This is currently explored as JEP 198: https://openjdk.org/jeps/198

* I think a very simple solution would be sufficient for shell script 
style programs.


## Conclusion

I think a few small additions to the standard library could solve these 
problems and be useful both to shell script style programs as well as 
other Java programs.

Best Regargs,
Jens Lidestr?m, Java and MUMPS developer

From liach at openjdk.org  Sun Oct  8 15:37:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 8 Oct 2023 15:37:17 GMT
Subject: RFR: 8315585: Optimization for decimal to string
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: 

On Mon, 2 Oct 2023 05:40:03 GMT, ???  wrote:

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster, Here are the numbers run on a MacBook M1 Pro:
> 
> 
> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
> -BigDecimals.testHugeToEngineeringString   avgt   15   228.102 ? 12.568  ns/op
> -BigDecimals.testLargeToEngineeringString  avgt   15    53.814 ?  0.180  ns/op
> -BigDecimals.testSmallToEngineeringString  avgt   15    17.521 ?  0.521  ns/op
> -BigDecimals.testToEngineeringString       avgt   15  1814.858 ? 64.432  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units ()
> +BigDecimals.testHugeToEngineeringString   avgt   15   209.579 ?  5.037  ns/op (+8.84)
> +BigDecimals.testLargeToEngineeringString  avgt   15    29.617 ?  0.557  ns/op (+81.70)
> +BigDecimals.testSmallToEngineeringString  avgt   15    11.230 ?  0.075  ns/op (+56.02)
> +BigDecimals.testToEngineeringString       avgt   15  1732.913 ? 33.629  ns/op (+4.73)
> 
> 
> Please review and don't hesitate to critique my approach and patch.

src/java.base/share/classes/java/math/BigDecimal.java line 4216:

> 4214:             int lowInt = (int) intCompact - highInt * 100;
> 4215:             int highIntSize = JLA.stringSize(highInt);
> 4216:             byte[] buf = new byte[highIntSize + 3];

I think the String concat indy call site already generates code that computes the size of the char array to be allocated (remember the lengthCoder from String Concat). We can probably just use `highInt + '.' + StringBuilderHelper.DIGIT_TENS[lowInt] + StringBuilderHelper.DIGIT_ONES[lowInt]`.

src/java.base/share/classes/java/math/BigDecimal.java line 4253:

> 4251:                 buf.append('0');
> 4252:                 buf.append('.');
> 4253:                 for (; pad>0; pad--) {

Can probably use `buf.repeat('0', pad)` now

src/java.base/share/classes/java/math/BigDecimal.java line 4280:

> 4278:         } else {
> 4279:             offset = 0;
> 4280:             coeff  = intVal.abs().toString().toCharArray();

It seems `coeff` is no longer modified after this point. I think you can just use a `String` for `coeff`, and `String` is already coder-optimized, you don't need to expose a StringBuilder.append via JLA.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1349723167
PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1349712188
PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1349717218

From darcy at openjdk.org  Sun Oct  8 17:04:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 8 Oct 2023 17:04:18 GMT
Subject: RFR: 8180892: Correct handling of annotations on parameters [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 27 Apr 2023 23:42:54 GMT, Joe Darcy  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix assuming match without MethodParameters for type annotations, move implementation related to getAnnotatedParameterTypes to around it
>
> @liach , thank you for working on this fix. I've given the changes an initial skim, but will need to do a more thorough review before approving or offering suggestions for changes. My top priority for the next few weeks will be JDK 21 CSRs so it may take a while for me to circle back to this PR.

> @jddarcy Joe, can you take a look at this patch where annotation handling on parameters now uses available `MethodParameters` attribute to match from explicit formal parameter indices to implicit formal parameter indices?

@liach sorry for the delays.

I'll be attending to some other matters in the immediate future; please ping me again in a few weeks if I don't reply first.

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

PR Comment: https://git.openjdk.org/jdk/pull/13664#issuecomment-1752105911

From duke at openjdk.org  Mon Oct  9 00:39:26 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 00:39:26 GMT
Subject: RFR: 8315585: Optimization for decimal to string
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Sun, 8 Oct 2023 15:30:00 GMT, Chen Liang  wrote:

> I think the String concat indy call site already generates code that computes the size of the char array to be allocated (remember the lengthCoder from String Concat). We can probably just use `highInt + '.' + StringBuilderHelper.DIGIT_TENS[lowInt] + StringBuilderHelper.DIGIT_ONES[lowInt]`.

The code of StringBuilderHelper is duplicated, I want to remove it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1349804946

From liangchenblue at gmail.com  Mon Oct  9 03:24:30 2023
From: liangchenblue at gmail.com (-)
Date: Mon, 9 Oct 2023 11:24:30 +0800
Subject: =?UTF-8?Q?Re=3A_Should_we_allow_use_Unsafe_or_ByteArrayLittleEnd?=
 =?UTF-8?Q?ian_for_trivial_byte=5B=5D_writes_in_core=2Dlibs=EF=BC=9F?=
In-Reply-To: <8561ed7c-6afc-4d16-ad71-b896f22e178d.shaojin.wensj@alibaba-inc.com>
References: <8561ed7c-6afc-4d16-ad71-b896f22e178d.shaojin.wensj@alibaba-inc.com>
Message-ID: 

Hello Wenshao and the core libraries mailing list,
First, I want to talk about the roles of Unsafe and BALE.
Unsafe itself is a collection of JVM-specific APIs that must be guarded
from dependent Java code. The set/getXxx methods are one set of such APIs
that directly utilizes unaligned reads and writes on supported platforms.
This set of APIs are already exposed to regular Java users via 2 public
APIs: ByteBuffer and VarHandle (MethodHandles.byteArrayViewVarHandle, used
by BALE), both of which are invoking the Unsafe API, and their overhead can
be eliminated by JIT.

Currently, we have a Vector API in incubation, which ensures vectorization
of some operations; our usage of BALE is similar, that we wish to
accomplish SLP reliably.

I took some time to look through where you use BALE to speed up writing: I
believe that performing the optimization at JIT level would be better if
possible, for the JIT knows the best way to group bytes together to write
at a given offset on an arbitrary platform (such as a big-endian one).
Similar to the Vector API, I think we might add new internal APIs like:
public static void write(byte[] arr, int offset, int b0, int b1, ....)
where we declare explicitly that we write multiple bytes at once so we know
JIT will reliably optimize our writes (if JIT have trouble optimizing SLP
like auto-vectorization)

Another reason JIT is better than reusing BALE/ByteBuffer is that their
resulting values are "meaningful"; i.e. the results are used directly and
the read/writes are 2-way. In our case, however, we are only interested in
faster writing, and there are multiple ways to group the writes, so I don't
think Java-based APIs will be useful.

For JVM startup, I recommend you to run a simple Hello World with
-Xlog:class+init flags to see what classes are initialized before
java/lang/invoke/MethodHandleImpl. In general, you shouldn't initialize
java.lang.invoke classes (lambdas, VarHandle, MethodHandle), such as by
keeping them in fields, in wrappers, String, collection, and reflection.
They can use lambdas in their methods, but those lambdas cannot be called
before java.lang.invoke is ready.

Best,
Chen Liang

On Sun, Oct 8, 2023 at 5:14?PM ???(??) 
wrote:

> Should we allow use Unsafe or ByteArrayLittleEndian for trivial byte[]
> writes in core-libs?
>
> There is already code that uses ByteArrayLittleEndian to improve
> performance, such as:
> ```java
> package java.util;
>
> class UUID {
>     public String toString() {
>         // ...
>         ByteArrayLittleEndian.setInt(
>                 buf,
>                 9,
>                 HexDigits.packDigits(((int) msb) >> 24, ((int) msb) >>
> 16));
>         // ...
>     }
> }
> ```
>
> There are examples of using ByteArrayLittleEndian and then removing it
> because it caused the JVM to start slowly (we can use
> Unsafe.putShortUnaligned to solve the problem of slow JVM startup)
> ```java
> package java.lang;
> class StringLatin1 {
>     private static void writeDigitPair(byte[] buf, int charPos, int value)
> {
>         short pair = DecimalDigits.digitPair(value);
>         // UNSAFE.putShortUnaligned(buf, ARRAY_BYTE_BASE_OFFSET + charPos,
> pair);
>         buf[charPos] = (byte)(pair);
>         buf[charPos + 1] = (byte)(pair >> 8);
>     }
> }
> ```
>
> Here is an example in the PR Review is disagreeing with the use of
> ByteArrayLittleEndian
> https://github.com/openjdk/jdk/pull/15768
> ```java
> package java.util;
> class HexFormat {
>     String formatOptDelimiter(byte[] bytes, int fromIndex, int toIndex) {
>     // ...
>         short pair = HexDigits.digitPair(bytes[fromIndex + i], ucase);
>         int pos = i * 2;
>         rep[pos] = (byte)pair;
>         rep[pos + 1] = (byte)(pair >>> 8);
>         // ByteArrayLittleEndian.setShort(rep, pos, pair);
>     }
> }
> ```
>
> This is another example of PR Review disagreeing with the use of
> ByteArrayLittleEndian.
> https://github.com/openjdk/jdk/pull/15990
> ```java
> package java.lang;
> class AbstractStringBuilder {
>     static final class Constants {
>         static final int NULL_LATIN1;
>         static final int NULL_UTF16;
>         static {
>             byte[] bytes4 = new byte[] {'t', 'r', 'u', 'e'};
>             byte[] bytes8 = new byte[8];
>             NULL_LATIN1 = ByteArrayLittleEndian.getInt(bytes4, 0);
>             StringLatin1.inflate(bytes4, 0, bytes8, 0, 4);
>             NULL_UTF16 = ByteArrayLittleEndian.getLong(bytes8, 0);
>         }
>     }
>
>     private AbstractStringBuilder appendNull() {
>         ensureCapacityInternal(count + 4);
>         int count = this.count;
>         byte[] val = this.value;
>         if (isLatin1()) {
>             ByteArrayLittleEndian.setInt(val, count,
> Constants.NULL_LATIN1);
>         } else {
>             ByteArrayLittleEndian.setLong(val, count << 1,
> Constants.NULL_UTF16);
>         }
>         this.count = count + 4;
>         return this;
>     }
> }
> ```
>
> In these examples, using Unsafe/ByteArrayLittleEndian significantly
> improves performance. If JIT automatic optimization is the best solution,
> but SuperWord Level Parallelism (SLP) does not currently support this
> optimization, what are our recommendations? What scenarios cannot use
> Unsafe, and what scenarios cannot use ByteArrayLittleEndian?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mbaesken at openjdk.org  Mon Oct  9 12:33:05 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 9 Oct 2023 12:33:05 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5
In-Reply-To: 
References: 
Message-ID: <_ueULKSdleQWKqK6FZ2wcz5d01mHfDtceqdbZ76Dmeg=.db424b77-3543-433a-af33-7618adb62085@github.com>

On Thu, 5 Oct 2023 10:02:05 GMT, Joachim Kern  wrote:

> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
> 
> test TreeTest.test5(): failure
> java.lang.AssertionError: expected direct children expected [2] but found [3]
>         at org.testng.Assert.fail(Assert.java:99)
>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>         at org.testng.Assert.assertEquals(Assert.java:122)
>         at org.testng.Assert.assertEquals(Assert.java:907)
>         at TreeTest.test5(TreeTest.java:447)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>         at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>         at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>         at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>         at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>         at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>         at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>         at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>         at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>         at org.testng.TestRunner.privateRun(TestRunner.java:764)
>         at org.testng.TestRunner.run(TestRunner.java:585)
>         at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>         at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>         at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>         at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>         at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>         at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>         at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>         at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>         at org.testng.TestNG.runSuites(TestNG.java:1069)
>         at org.testng.TestNG.run(TestNG.java:1037)
>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(...

Please add some describing comments to  os_getChildren;  for an example see 
src/java.base/macosx/native/libjava/ProcessHandleImpl_macosx.c

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1752920865

From asotona at openjdk.org  Mon Oct  9 14:09:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 9 Oct 2023 14:09:29 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v16]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - removed AttributeMapper::validSince
 - fixed DirectCodeBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/7fe5db2b..21f4bb03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=14-15

  Stats: 105 lines in 25 files changed: 47 ins; 30 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From mchhipa at openjdk.org  Mon Oct  9 14:42:33 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Mon, 9 Oct 2023 14:42:33 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v8]
In-Reply-To: 
References: 
Message-ID: 

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request with a new target base 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:

 - Implemented the review comments.
   1. Now test uses Junit5.
   2. Created the seperate Utility class to generate the JDK version specific java src file.
 - Merge branch 'master' into JDK-8077371
 - Implemented review comments.
 - Implemented the review comments.
 - Move the pseudo code generation part from setup() to seperate methods.
 - 1. Added JDK version in Data files.
   2. Updated copyright year.
 - Implemented the review comments.
 - Implemented the review comment.
 - closed file handlers.
 - JDK-8077371: Binary files in JAXP test should be removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/a940f237..a01dc7e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=06-07

  Stats: 830759 lines in 11186 files changed: 571572 ins; 156454 del; 102733 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From iris at openjdk.org  Mon Oct  9 14:43:10 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 9 Oct 2023 14:43:10 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v16]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Thu, 5 Oct 2023 20:02:44 GMT, ???  wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> ??? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add copyright info
>  - Improve the readability, suggestion from @rgiulietti

test/jdk/java/util/Formatter/BasicInt.java line 404:

> 402: 
> 403:         // non-conversion
> 404:         tryCatch("%12", UnknownFormatConversionException.class);

Is this file still mechanically generated as indicated in line 31 (above)?  Perhaps these changes should be in Basic-X.java.template instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1350397453

From jkern at openjdk.org  Mon Oct  9 15:00:18 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 9 Oct 2023 15:00:18 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v2]
In-Reply-To: 
References: 
Message-ID: 

> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
> 
> test TreeTest.test5(): failure
> java.lang.AssertionError: expected direct children expected [2] but found [3]
>         at org.testng.Assert.fail(Assert.java:99)
>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>         at org.testng.Assert.assertEquals(Assert.java:122)
>         at org.testng.Assert.assertEquals(Assert.java:907)
>         at TreeTest.test5(TreeTest.java:447)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>         at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>         at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>         at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>         at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>         at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>         at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>         at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>         at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>         at org.testng.TestRunner.privateRun(TestRunner.java:764)
>         at org.testng.TestRunner.run(TestRunner.java:585)
>         at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>         at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>         at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>         at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>         at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>         at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>         at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>         at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>         at org.testng.TestNG.runSuites(TestNG.java:1069)
>         at org.testng.TestNG.run(TestNG.java:1037)
>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(...

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16051/files
  - new: https://git.openjdk.org/jdk/pull/16051/files/661bcf33..f7b2a47d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16051&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16051&range=00-01

  Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16051.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16051/head:pull/16051

PR: https://git.openjdk.org/jdk/pull/16051

From stuefe at openjdk.org  Mon Oct  9 15:05:02 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Oct 2023 15:05:02 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 9 Oct 2023 15:00:18 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> 
>> test TreeTest.test5(): failure
>> java.lang.AssertionError: expected direct children expected [2] but found [3]
>>         at org.testng.Assert.fail(Assert.java:99)
>>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>>         at org.testng.Assert.assertEquals(Assert.java:122)
>>         at org.testng.Assert.assertEquals(Assert.java:907)
>>         at TreeTest.test5(TreeTest.java:447)
>>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>>         at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>         at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>         at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>         at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>         at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>         at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>         at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>         at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>         at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>>         at org.testng.TestRunner.privateRun(TestRunner.java:764)
>>         at org.testng.TestRunner.run(TestRunner.java:585)
>>         at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>>         at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>>         at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>>         at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>>         at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>>         at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>>         at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>>         at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>>         at org.testng.TestNG.runSuites(TestNG.java:1069)
>>         at org.testng.TestNG.run(TestNG.java:1037)
>>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
>>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
>>     ...
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment

@JoKern65 could you explain a bit what the patch wants to do?

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1753181485

From asotona at openjdk.org  Mon Oct  9 15:11:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 9 Oct 2023 15:11:23 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v17]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - fixed exception type thrown from CodeImpl
 - added constraint to throw on an attempt to parse unknown classfile version
   + test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/21f4bb03..ad6aadf1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=15-16

  Stats: 13 lines in 4 files changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From jkern at openjdk.org  Mon Oct  9 15:18:59 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 9 Oct 2023 15:18:59 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v2]
In-Reply-To: 
References: 
 
Message-ID: <3vK2TqpHqycR9OJU6g4nB0z-12zbZGv35U3t3sRz4_I=.bea2a3c0-b8cf-44bd-b50f-a98ca954091e@github.com>

On Mon, 9 Oct 2023 15:00:18 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> 
>> test TreeTest.test5(): failure
>> java.lang.AssertionError: expected direct children expected [2] but found [3]
>>         at org.testng.Assert.fail(Assert.java:99)
>>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>>         at org.testng.Assert.assertEquals(Assert.java:122)
>>         at org.testng.Assert.assertEquals(Assert.java:907)
>>         at TreeTest.test5(TreeTest.java:447)
>>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>>         at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>         at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>         at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>         at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>         at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>         at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>         at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>         at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>         at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>>         at org.testng.TestRunner.privateRun(TestRunner.java:764)
>>         at org.testng.TestRunner.run(TestRunner.java:585)
>>         at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>>         at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>>         at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>>         at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>>         at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>>         at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>>         at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>>         at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
>>         at org.testng.TestNG.runSuites(TestNG.java:1069)
>>         at org.testng.TestNG.run(TestNG.java:1037)
>>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
>>         at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
>>     ...
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment

Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1753204828

From stuefe at openjdk.org  Mon Oct  9 15:32:00 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Oct 2023 15:32:00 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v2]
In-Reply-To: <3vK2TqpHqycR9OJU6g4nB0z-12zbZGv35U3t3sRz4_I=.bea2a3c0-b8cf-44bd-b50f-a98ca954091e@github.com>
References: 
 
 <3vK2TqpHqycR9OJU6g4nB0z-12zbZGv35U3t3sRz4_I=.bea2a3c0-b8cf-44bd-b50f-a98ca954091e@github.com>
Message-ID: 

On Mon, 9 Oct 2023 15:15:52 GMT, Joachim Kern  wrote:

> Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.

Okay, thanks. Could you add this to the PR description so that when we look at this PR, we don't have to scroll through comment history? Ideally, this would be in the JBS bug description, too.

Cheers, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1753229086

From roger.riggs at oracle.com  Mon Oct  9 16:04:58 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 9 Oct 2023 12:04:58 -0400
Subject: ISO Starndard Date Format implementation consistency on
 DateTimeFormatter and String.format
In-Reply-To: <875b3104-40f7-48b9-b003-b19ac5e2ce09.shaojin.wensj@alibaba-inc.com>
References: <875b3104-40f7-48b9-b003-b19ac5e2ce09.shaojin.wensj@alibaba-inc.com>
Message-ID: <96927d6d-6606-69b7-d208-31862b156d77@oracle.com>

Hi,

Java.time has a clear definition of negative years.
It would need a closer look as to j.u.Formatter's interpretation of 
negative years, though it should be consistent for j.t.LocalDate.

Created:
8317742  ISO Starndard Date 
Format implementation consistency on DateTimeFormatter and String.format

Regards, Roger


On 10/4/23 10:22 AM, ???(??) wrote:
> j.t.DateTimeFormatter defines ISO_LOCAL_DATE, j.u.Formatter.DateTime 
> also defines ISO_STANDARD_DATE ("%tF"), and now their behavior is 
> different outside the range of [0,9999],?We run the following code and 
> we can see their different behaviors:
>
> ```java
> DateTimeFormatter formatter = DateTimeFormatter.ISO_LOCAL_DATE;
> int[] years = {-99999, -9999, -999, -99, -9, 0, 9, 99, 999, 1999, 
> 2999, 9999, 99999};
> for (int year : years) {
> ? ? LocalDate localDate = LocalDate.of(year, 1, 1);
> System.out.println(formatter.format(localDate) + "\t\t->\t\t" + 
> "%tF".formatted(localDate));
> }
> ```
>
> * output
> ```
> -99999-01-01? -> 100000-01-01
> -9999-01-01? ->? 10000-01-01
> -0999-01-01? ->? 1000-01-01
> -0099-01-01? ->? 0100-01-01
> -0009-01-01? ->? 0010-01-01
> 0000-01-01? ->? 0001-01-01
> 0009-01-01? ->? 0009-01-01
> 0099-01-01? ->? 0099-01-01
> 0999-01-01? ->? 0999-01-01
> 1999-01-01? ->? 1999-01-01
> 2999-01-01? ->? 2999-01-01
> 9999-01-01? ->? 9999-01-01
> +99999-01-01? ->? 99999-01-01
> ```
>
> Should we keep it consistent?
>
> - wenshao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From naoto at openjdk.org  Mon Oct  9 16:33:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Oct 2023 16:33:12 GMT
Subject: Integrated: 8317471: ListFormat::parseObject() spec can be improved on
 parsePosition valid values
In-Reply-To: 
References: 
Message-ID: 

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato  wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 1f063251
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/1f063251429a3f6fc1d76911ed7802ad3108a546
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8317471: ListFormat::parseObject() spec can be improved on parsePosition valid values

Reviewed-by: iris, lancea, joehw, mli

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

PR: https://git.openjdk.org/jdk/pull/16063

From abimpoudis at openjdk.org  Mon Oct  9 16:53:22 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 9 Oct 2023 16:53:22 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v14]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <9dRLbVIVYt77YCrnbFnZY4b-bAh572yvBj5GhETNCVM=.d7e8c829-c3d7-452b-883f-5bdac26d5d72@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with five additional commits since the last revision:

 - Fix exhaustiveness check for primitive types
 - Add tests
 - Improve non integral check
 - Fixing error conditions, tweaking tests.
 - Attempting to improve reported errors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/f1a5e141..cdaa186c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=12-13

  Stats: 496 lines in 13 files changed: 351 ins; 84 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From psandoz at openjdk.org  Mon Oct  9 17:47:35 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 9 Oct 2023 17:47:35 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: <6IgF8wcto7s8tj_yB733vzEUB_3f1pmJVXqKsMeoQ2w=.9b008a1a-aaed-4879-b8a0-6ef41fc87a08@github.com>
References: 
 
 <6IgF8wcto7s8tj_yB733vzEUB_3f1pmJVXqKsMeoQ2w=.9b008a1a-aaed-4879-b8a0-6ef41fc87a08@github.com>
Message-ID: 

On Sun, 8 Oct 2023 06:18:13 GMT, Danny Thomas  wrote:

>> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - fix code style and formatting
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>>  - change variable names of indexPivot* to pivotIndex*
>>  - Update DualPivotQuicksort.java
>>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>>  - Remove the unnecessary exception in single pivot partitioning fallback method
>>  - Move functional interfaces close to the associated methods
>>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>>  - Refactor stub handling to use a generic function for all types
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86
>
> A [discussion on Reddit](https://www.reddit.com/r/java/comments/171t5sj/heads_up_openjdk_implementation_of_avx512_based/) raised that this had the potential to regress sort performance on AMD Zen 4. The poster didn't have access to Zen 4 hardware, so I took a moment to run the benchmark, comparing against a baseline with `UseAVX=2` on an AWS `m7a.2xlarge`:
> 
> 
> processor	: 0
> vendor_id	: AuthenticAMD
> cpu family	: 25
> model		: 17
> model name	: AMD EPYC 9R14
> stepping	: 1
> microcode	: 0xa10113e
> cpu MHz		: 3673.537
> cache size	: 1024 KB
> physical id	: 0
> siblings	: 8
> core id		: 0
> cpu cores	: 8
> apicid		: 0
> initial apicid	: 0
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 16
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf tsc_known_freq pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch topoext perfctr_core invpcid_single ssbd perfmon_v2 ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx512_bf16 clzero xsaveerptr rdpru wbnoinvd arat avx512vbmi pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid flush_l1d
> bugs		: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
> bogomips	: 5200.00
> TLB size	: 3584 4K pages
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 48 bits physical, 48 bits virtual
> power management:
> 
> 
> 
> $ make test TEST="micro:java.lang.ArraysSort.intSort"
> 
> Benchmark            (size)  Mode  Cnt      Score     Error  Units
> ArraysSort.intSort       10  avgt    3      0.033 ?   0.001  us/op
> ArraysSort.intSort       25  avgt    3      0.067 ?   0.002  us/op
> ArraysSort.intSort       50  avgt    3      0.391 ?   0.007  us/op
> ArraysSort.intSort       75  avgt    3      0.923 ?   0.041  us/op
> ArraysSort.intSort      100  avgt    3      1.292 ?   0.009  us/op
> ArraysSort.intSort     1000  avgt    3     24.268 ?   0.078  us/op
> ArraysSort.intSort    10000  avgt    3    320.131 ?   0.381  us/op
> ArraysSort.intSort   100000  avgt    3   4803.142 ?  63.901  us/op
> ArraysSort.intSort  1000000  avgt    3  61457.708 ? 347.446  us/op
> 
> 
> 
> $ make test TEST="micro:java.lang.ArraysSort.intSort" MICRO...

@DanielThomas thank you, i was not aware of the limitation on AMD Zen 4. We need to address this and it appears the fix is simple and localized. Thankfully we are early into the JDK 22 development cycle so we have time to shake this out.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1753412092

From psandoz at openjdk.org  Mon Oct  9 18:18:36 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 9 Oct 2023 18:18:36 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - fix code style and formatting
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>  - change variable names of indexPivot* to pivotIndex*
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>  - Remove the unnecessary exception in single pivot partitioning fallback method
>  - Move functional interfaces close to the associated methods
>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>  - Refactor stub handling to use a generic function for all types
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86

> _Mailing list message from [Florian Weimer](mailto:fw at deneb.enyo.de) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.org):_
> 
> I believe this has introduced a build failure with GCC 12.2 on Debian 12.1:
> 

I believe it due to an issue in GCC 12 that has yet to be resolved:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593

We (Oracle) currently build with GCC 11.2.0 (https://wiki.openjdk.org/display/Build/Supported+Build+Platforms) so i expect we will encounter the same problem when upgrading to the 12 toolchain.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1753448917

From duke at openjdk.org  Mon Oct  9 18:55:15 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 18:55:15 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency on
 DateTimeFormatter and String.format
Message-ID: 

j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

Commit messages:
 - fix format ""%tF" (iso standard date) not correct

Changes: https://git.openjdk.org/jdk/pull/16033/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317742
  Stats: 32 lines in 2 files changed: 30 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16033/head:pull/16033

PR: https://git.openjdk.org/jdk/pull/16033

From duke at openjdk.org  Mon Oct  9 18:55:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 18:55:17 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format
In-Reply-To: 
References: 
Message-ID: <_zEtAAwoWQV9IgXbd7YAznfUFwiUHNk1dxEsmiPQFHE=.de31d46a-569f-4955-8e63-3e5b0a49099e@github.com>

On Tue, 3 Oct 2023 21:37:46 GMT, ???  wrote:

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

@cl4es could you please review my code? Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1745811258

From redestad at openjdk.org  Mon Oct  9 18:55:18 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Oct 2023 18:55:18 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format
In-Reply-To: 
References: 
Message-ID: <5yszZPmmqYlqqr0k1IaAEuo6MZn6kobzxRLt3lWWFyc=.c96dc45f-b30f-4752-8597-38083b8044bb@github.com>

On Tue, 3 Oct 2023 21:37:46 GMT, ???  wrote:

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

I think this deserves a discussion on the mailing list before jumping to a PR, as neither `%tF` nor the ISO-8601 standard it defers to is particularly well-defined outside of the range 0-9999

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1746690241

From duke at openjdk.org  Mon Oct  9 18:55:19 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 18:55:19 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format
In-Reply-To: <5yszZPmmqYlqqr0k1IaAEuo6MZn6kobzxRLt3lWWFyc=.c96dc45f-b30f-4752-8597-38083b8044bb@github.com>
References: 
 <5yszZPmmqYlqqr0k1IaAEuo6MZn6kobzxRLt3lWWFyc=.c96dc45f-b30f-4752-8597-38083b8044bb@github.com>
Message-ID: 

On Wed, 4 Oct 2023 11:33:16 GMT, Claes Redestad  wrote:

> I think this deserves a discussion on the mailing list before jumping to a PR, as neither `%tF` nor the ISO-8601 standard it defers to is particularly well-defined outside of the range 0-9999

Thank you @cl4es for your suggestion, I have sent an email to mailing.

j.t.DateTimeFormatter defines ISO_LOCAL_DATE, j.u.Formatter.DateTime also defines ISO_STANDARD_DATE ("%tF"), and now their behavior is different outside the range of [0,9999], We run the following code and we can see their different behaviors:


DateTimeFormatter formatter = DateTimeFormatter.ISO_LOCAL_DATE;
int[] years = {-99999, -9999, -999, -99, -9, 0, 9, 99, 999, 1999, 2999, 9999, 99999};
for (int year : years) {
    LocalDate localDate = LocalDate.of(year, 1, 1);
    System.out.println(formatter.format(localDate) + "\t\t->\t\t" + "%tF".formatted(localDate));
}


* output

-99999-01-01  ->  100000-01-01
-9999-01-01   ->  10000-01-01
-0999-01-01   ->  1000-01-01
-0099-01-01   ->  0100-01-01
-0009-01-01   ->  0010-01-01
0000-01-01    ->  0001-01-01
0009-01-01    ->  0009-01-01
0099-01-01    ->  0099-01-01
0999-01-01    ->  0999-01-01
1999-01-01    ->  1999-01-01
2999-01-01    ->  2999-01-01
9999-01-01    ->  9999-01-01
+99999-01-01  ->  99999-01-01

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1746990262

From duke at openjdk.org  Mon Oct  9 18:55:43 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 9 Oct 2023 18:55:43 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
Message-ID: <5ihPztw6IW-h1Akp33Z7Dr_Rm-wfenP9B46_6e0ETIc=.16e8a413-8810-4540-aca4-c1da61ab4235@github.com>

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - fix code style and formatting
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>  - change variable names of indexPivot* to pivotIndex*
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>  - Remove the unnecessary exception in single pivot partitioning fallback method
>  - Move functional interfaces close to the associated methods
>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>  - Refactor stub handling to use a generic function for all types
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86

> _Mailing list message from [Florian Weimer](mailto:fw at deneb.enyo.de) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.org):_
> 
> I believe this has introduced a build failure with GCC 12.2 on Debian 12.1:
> 
> Building target 'jdk' in configuration '/home/fw/build/jdk' In file included from /usr/lib/gcc/x86_64-linux-gnu/12/include/immintrin.h:49, from ?/jdk/src/java.base/linux/native/libsimdsort/avx512-common-qsort.h:60, from ?/jdk/src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp:31, from ?/jdk/src/java.base/linux/native/libsimdsort/avx512-linux-qsort.cpp:26: In function '__m512i _mm512_shuffle_epi32(__m512i, _MM_PERM_ENUM)', inlined from 'static zmm_vector::zmm_t zmm_vector::shuffle(zmm_t) [with unsigned char mask = 177]' at ?/jdk/src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp:96:36, inlined from 'zmm_t sort_zmm_32bit(zmm_t) [with vtype = zmm_vector; zmm_t = __vector(8) long long int]' at ?/jdk/src/java.base/linux/native/libsimdsort/avx512-32bit-qsort.hpp:170:27: /usr/lib/gcc/x86_64-linux-gnu/12/include/avx512fintrin.h:4459:50: error: '__Y' is used uninitialized [-Werror=uninitialized] 4459 | return (__m512i) __builtin_ia32_pshufd512_mask ((__v
 16si) __A, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ 4460 | __mask, | ~~~~~~~ 4461 | (__v16si) | ~~~~~~~~~ 4462 | _mm512_undefined_epi32 (), | ~~~~~~~~~~~~~~~~~~~~~~~~~~ 4463 | (__mmask16) -1); | ~~~~~~~~~~~~~~~ /usr/lib/gcc/x86_64-linux-gnu/12/include/avx512fintrin.h: In function 'zmm_t sort_zmm_32bit(zmm_t) [with vtype = zmm_vector; zmm_t = __vector(8) long long int]': /usr/lib/gcc/x86_64-linux-gnu/12/include/avx512fintrin.h:206:11: note: '__Y' was declared here 206 | __m512i __Y = __Y; | ^~~

Hello Florian (@fweimer),

As Paul mentioned, this is an issue in GCC 12. 
Will reproduce it on my side and issue a workaround [PR](https://bugs.openjdk.org/browse/JDK-8317741) shortly to address this issue.

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1753490421

From duke at openjdk.org  Mon Oct  9 19:00:40 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 9 Oct 2023 19:00:40 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: <6IgF8wcto7s8tj_yB733vzEUB_3f1pmJVXqKsMeoQ2w=.9b008a1a-aaed-4879-b8a0-6ef41fc87a08@github.com>
References: 
 
 <6IgF8wcto7s8tj_yB733vzEUB_3f1pmJVXqKsMeoQ2w=.9b008a1a-aaed-4879-b8a0-6ef41fc87a08@github.com>
Message-ID: 

On Sun, 8 Oct 2023 06:18:13 GMT, Danny Thomas  wrote:

> A [discussion on Reddit](https://www.reddit.com/r/java/comments/171t5sj/heads_up_openjdk_implementation_of_avx512_based/) raised that this had the potential to regress sort performance on AMD Zen 4. The poster didn't have access to Zen 4 hardware, so I took a moment to run the benchmark, comparing against a baseline with `UseAVX=2` on an AWS `m7a.2xlarge`:
> 

Hello Daniel (@DanielThomas ),

Thank you for sharing the data. Will issue a new PR to restrict the AVX512 sort to Intel CPUs only for the time being.

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1753495000

From bpb at openjdk.org  Mon Oct  9 19:02:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Oct 2023 19:02:19 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v5]
In-Reply-To: 
References: 
Message-ID: 

> Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely.

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

 - Merge
 - 6478546: do-while -> while-do in writeBytes; remove NULL and bounds checks in native
 - 6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy
 - 6478546: Decrease malloc limit to 1.5 MB
 - 6478546: Minor refactoring
 - 6478546: Prevent short read
 - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14981/files
  - new: https://git.openjdk.org/jdk/pull/14981/files/cdb8455c..3a016a72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=03-04

  Stats: 200415 lines in 4979 files changed: 96645 ins; 49069 del; 54701 mod
  Patch: https://git.openjdk.org/jdk/pull/14981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14981/head:pull/14981

PR: https://git.openjdk.org/jdk/pull/14981

From duke at openjdk.org  Mon Oct  9 19:20:29 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 19:20:29 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v2]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: 

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster, Here are the numbers run on a MacBook M1 Pro:
> 
> 
> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
> -BigDecimals.testHugeToEngineeringString   avgt   15   228.102 ? 12.568  ns/op
> -BigDecimals.testLargeToEngineeringString  avgt   15    53.814 ?  0.180  ns/op
> -BigDecimals.testSmallToEngineeringString  avgt   15    17.521 ?  0.521  ns/op
> -BigDecimals.testToEngineeringString       avgt   15  1814.858 ? 64.432  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units ()
> +BigDecimals.testHugeToEngineeringString   avgt   15   209.579 ?  5.037  ns/op (+8.84)
> +BigDecimals.testLargeToEngineeringString  avgt   15    29.617 ?  0.557  ns/op (+81.70)
> +BigDecimals.testSmallToEngineeringString  avgt   15    11.230 ?  0.075  ns/op (+56.02)
> +BigDecimals.testToEngineeringString       avgt   15  1732.913 ? 33.629  ns/op (+4.73)
> 
> 
> Please review and don't hesitate to critique my approach and patch.

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

  refactor based on @liach 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/a8ec3c57..05406d99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=00-01

  Stats: 220 lines in 6 files changed: 47 ins; 139 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From lancea at openjdk.org  Mon Oct  9 19:40:58 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 9 Oct 2023 19:40:58 GMT
Subject: RFR: JDK-8317633: Modernize text.testlib.HexDumpReader [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 21:07:51 GMT, Justin Lu  wrote:

>> Please review this PR which cleans up the static test utility class _HexDumpReader_.
>> 
>> This cleans up the code by replacing the nested _ByteArrayBuilder_ class with _HexFormat_, and simplifies the File processing by using a stream. Changes were tested to ensure that the _text_ tests are still getting equivalent ByteArrayInputStreams as before.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comments

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16075#pullrequestreview-1665156750

From roger.riggs at oracle.com  Mon Oct  9 19:45:47 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 9 Oct 2023 15:45:47 -0400
Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mkFkZGluZyBhcHBlbmRIZXggbWV0aG9kIHRvIFN0?=
 =?UTF-8?Q?ringBuilder?=
In-Reply-To: <0a97f39e-953d-4530-add3-29560d29303d.shaojin.wensj@alibaba-inc.com>
References: 
 
 <20231002081855.176913415@eggemoggin.niobe.net>
 
 <0a97f39e-953d-4530-add3-29560d29303d.shaojin.wensj@alibaba-inc.com>
Message-ID: 

Hi,

The j.u.HexFormat class has methods that append hex formatted byte 
arrays to an Appendable such as StringBuilder.

The `toHexDigits` methods return strings with the hex values of byte, 
short, char, int, and long.

Similar `formatHex` methods could be added with an Appendable argument 
would keep the focus in HexFormat for the formatting but allows the 
result to be placed directly in a StringBuilder.

For example in this draft PR. https://github.com/openjdk/jdk/pull/16105

Regards, Roger


On 10/2/23 10:01 AM, ???(??) wrote:
> StringTemplate is great and I wish I can submit PR to improve it. But 
> I still think StringBuilder.appendHex is a basic API, not a formatted 
> API. Just like Integer.toHexString and Long.toHexString, they are very 
> commonly used and should be built-in.
>
>     ------------------------------------------------------------------
>     ???????(??) 
>     ?????2023?10?2?(???) 20:46
>     ????Mark Reinhold ; Claes Redestad
>     
>     ????core-libs-dev at openjdk.org 
>     ???????Adding appendHex method to StringBuilder
>
>     Using String Template FMT has better performance and better code
>     readability. But String Template does not yet support
>     for/while/if/switch. Is there any plan to enhance String Template
>     to support for/while/if/switch? The following scenarios cannot be
>     implemented using String.format or String Template. I think
>     whether to build in support for foo(bar(x)) depends on whether it
>     is a common enough method.
>
>     ```java
>     package java.net;
>     class Inet6Address extends InetAddress {
>     ? ? static String numericToTextFormat(byte[] src) {
>     ? ? ? ? StringBuilder sb = new StringBuilder(39);
>     ? ? ? ? for (int i = 0; i < (INADDRSZ / INT16SZ); i++) {
>     sb.append(Integer.toHexString(((src[i<<1]<<8) & 0xff00)
>     ? ? ? ? ? | (src[(i<<1)+1] & 0xff)));
>     ? ? ? ? ? ? if (i < (INADDRSZ / INT16SZ) -1 ) {
>     ? ? ? ? ? ? ? sb.append(":");
>     ? ? ? ? ? ? }
>     ? ? ? ? }
>     ? ? ? ? return sb.toString();
>     ? ? }
>     }
>     class SocketPermission {
>     ? private boolean authorizedIPv6(String cname, byte[] addr) {
>     ? ? ? ? String authHost = "";
>     ? ? ? ? InetAddress auth;
>     ? ? ? ? try {
>     ? ? ? ? ? ? StringBuilder sb = new StringBuilder(39);
>     ? ? ? ? ? ? for (int i = 15; i >= 0; i--) {
>     sb.append(Integer.toHexString(((addr[i]) & 0x0f)));
>     ? ? ? ? ? ? ? ? sb.append('.');
>     sb.append(Integer.toHexString(((addr[i] >> 4) & 0x0f)));
>     ? ? ? ? ? ? ? ? sb.append('.');
>     ? ? ? ? ? ? }
>     ? ? ? ? ...
>     ? }
>     }
>     ```
>     ```java
>     package sun.security.krb5.internal.crypto.dk;
>     class DkCrypto {
>     ? ? static String bytesToString(byte[] digest) {
>     ? ? ? ? // Get character representation of digest
>     ? ? ? ? StringBuilder digestString = new StringBuilder();
>     ? ? ? ? for (int i = 0; i < digest.length; i++) {
>     ? ? ? ? ? ? if ((digest[i] & 0x000000ff) < 0x10) {
>     digestString.append('0').append(Integer.toHexString(digest[i] &
>     0x000000ff));
>     ? ? ? ? ? ? } else {
>     digestString.append(
>     Integer.toHexString(digest[i] & 0x000000ff));
>     ? ? ? ? ? ? }
>     ? ? ? ? }
>     ? ? ? ? return digestString.toString();
>     ? ? }
>     }
>     ```
>
>     - wenshao
>
>     ------------------------------------------------------------------
>     ????Mark Reinhold 
>     ?????2023?10?2?(???) 20:19
>     ????Claes Redestad 
>     ???????(??) ;
>     core-libs-dev at openjdk.org 
>     ????Re: Adding appendHex method to StringBuilder
>
>     2023/10/2 7:22:55 -0400, claes.redestad at oracle.com:
>     > I think this goes against the grain: StringBuilder is a simple
>     builder
>     > for non-localized unformatted output. For formatted output there?s
>     > Formatter, String.format and, with JEP 430[1], FMT."..." to help
>     output
>     > string data in more advanced, formatted and localized ways.
>
>     Agreed.
>
>     If we were to introduce a `fooBar(x)` method for every common
>     `foo(bar(x))` expression in the JDK code base then our APIs
>     would fast become inscrutable.
>
>     - Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rriggs at openjdk.org  Mon Oct  9 19:56:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Oct 2023 19:56:57 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format
In-Reply-To: 
References: 
Message-ID: <7a9UpDFuo2J5OZKAK2dD8Mr4gnq_DgRhjGLTfuGeUL4=.d3a7bcc7-0cef-4b6a-bd4e-71d93149ece0@github.com>

On Tue, 3 Oct 2023 21:37:46 GMT, ???  wrote:

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

This PR will need an evaluation of the compatibility risk of changing the behavior, describing existing uses and scope and how they might be affected by the change.

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1753645657

From rriggs at openjdk.org  Mon Oct  9 20:11:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Oct 2023 20:11:59 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format
In-Reply-To: 
References: 
Message-ID: 

On Tue, 3 Oct 2023 21:37:46 GMT, ???  wrote:

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

The CSR is created, if you can provide (as a comment on the PR) the descriptions as described in the template, I can put them in the CSR.
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1753681822

From duke at openjdk.org  Mon Oct  9 20:24:01 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 20:24:01 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v2]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Mon, 9 Oct 2023 19:20:29 GMT, ???  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor based on @liach 's review

Based on @liach 's review suggestions, I reduced the changes to JavaLangAccess and further removed the duplicate code in BigDecimal.

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1753712589

From duke at openjdk.org  Mon Oct  9 20:40:43 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 20:40:43 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v17]
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
Message-ID: 

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

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

  move testcase from BasicInt to Basic-X

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/7a1cd112..134f2b22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=15-16

  Stats: 12 lines in 2 files changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15776/head:pull/15776

PR: https://git.openjdk.org/jdk/pull/15776

From duke at openjdk.org  Mon Oct  9 20:59:29 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 9 Oct 2023 20:59:29 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 
Message-ID: <2zPMXN5D81mImAkKn3txhUoOuBf6Aq69Hg14nI24cgQ=.57c2ecf0-5686-4292-b3df-e65a95187075@github.com>

On Mon, 9 Oct 2023 18:15:12 GMT, Paul Sandoz  wrote:

> > _Mailing list message from [Florian Weimer](mailto:fw at deneb.enyo.de) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.org):_
> > I believe this has introduced a build failure with GCC 12.2 on Debian 12.1:
> 
> I believe it due to an issue in GCC 12 that has yet to be resolved:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
> 
> We (Oracle) currently build with GCC 11.2.0 (https://wiki.openjdk.org/display/Build/Supported+Build+Platforms) so i expect we will encounter the same problem when upgrading to the 12 toolchain.

Hello Paul (@PaulSandoz) and Florian (@fweimer),

Just did a successful OpenJDK build (without any of the errors reported) using the latest GCC 12 (12.3.1) . Looks like this issue is fixed in `gcc 12.3.1`. 

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1753846401

From abimpoudis at openjdk.org  Mon Oct  9 21:08:42 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 9 Oct 2023 21:08:42 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v15]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Adjust tests
  
  Co-authored-by: Jan Lahoda 
  Co-authored-by: Angelos Bimpoudis 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/cdaa186c..bab26337

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=13-14

  Stats: 96 lines in 9 files changed: 34 ins; 56 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From duke at openjdk.org  Mon Oct  9 22:30:57 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 22:30:57 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format
In-Reply-To: 
References: 
Message-ID: 

On Tue, 3 Oct 2023 21:37:46 GMT, ???  wrote:

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

When String.format handles "%tF" Specifier, it uses the same behavior as DateTimeFormatter. This will cause the value of printed year to be incompatible with the previous behavior.

The year value range [-?, -1000] changes:

// String.format("%tF", LocalDate.of(-10000, 1, 1))
before 10001-01-01
after  -99999-01-01


The year value range [-9999, -1] changes: 

// String.format("%tF", LocalDate.of(-1, 1, 1))
before 0002-01-01
after  -0001-01-01


The year value range [-?, -1000] changes:

//String.format("%tF", LocalDate.of(10000, 1, 1)):
before 10000-01-01
after  +10000-01-01

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1753981207

From jlu at openjdk.org  Mon Oct  9 22:41:09 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Oct 2023 22:41:09 GMT
Subject: Integrated: JDK-8317631: Refactor ChoiceFormat tests to use JUnit
In-Reply-To: 
References: 
Message-ID: <9v3POWePTOooQ6yh79vwAu4_wLA_Sg5c1v1huzmQAGs=.2d458666-2c08-422c-8a5e-be75fccda365@github.com>

On Thu, 5 Oct 2023 20:57:07 GMT, Justin Lu  wrote:

> Please review this PR which refactors the ChoiceFormat tests to use JUnit.

This pull request has now been integrated.

Changeset: 5e8d893c
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/5e8d893c4809fdb30e01bdfe06b4f488f7bbef83
Stats:     165 lines in 3 files changed: 90 ins; 38 del; 37 mod

8317631: Refactor ChoiceFormat tests to use JUnit

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/16065

From naoto at openjdk.org  Mon Oct  9 22:47:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Oct 2023 22:47:16 GMT
Subject: RFR: JDK-8317372: Refactor some NumberFormat tests to use JUnit
In-Reply-To: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
Message-ID: 

On Tue, 3 Oct 2023 22:23:11 GMT, Justin Lu  wrote:

> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
> 
> During the switch to JUnit, the tests had the following updates (to improve readability)
> - separate the test data generation from the actual execution of the test
> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

test/jdk/java/text/Format/NumberFormat/BigDecimalCompatibilityTest.java line 162:

> 160:         // Check parse and returned value
> 161:         Number parsedValue = assertDoesNotThrow(()-> df.parse(longString),
> 162:                 "Should not throw a ParseException");

It could catch any exception, so the message could be broader. Maybe just `a ParseException` -> `an Exception`.

test/jdk/java/text/Format/NumberFormat/Bug4838107.java line 254:

> 252:                     "\n\tre-parsed number: " + parsed2 +
> 253:                     "  (" + parsed2.getClass().getName() + ")" +
> 254:                     "\n\tminus sign: " + df.getDecimalFormatSymbols().getMinusSign());

Could use text block to get rid of `\n`/`\t`s, with `.formatted()`. Same for the following one.

test/jdk/java/text/Format/NumberFormat/Bug4944439.java line 71:

> 69:     public void parseLongTest(String s) {
> 70:         Number parsedNumber = assertDoesNotThrow(() -> df.parse(s),
> 71:                 "DecimalFormat.parse(\"%s\") should not throw ParseException");

`ParseException` -> `Exception`. Applies to other locations

test/jdk/java/text/Format/NumberFormat/Bug4990596.java line 45:

> 43:     public void formatSubclassedNumberTest() {
> 44:         assertDoesNotThrow(() -> new DecimalFormat().format(new MutableInteger(0)),
> 45:                 "DecimalFormat.parse() should support subclasses of Number");

DecimalFormat.format()?

test/jdk/java/text/Format/NumberFormat/Bug8132125.java line 47:

> 45:         NumberFormat nf = NumberFormat.getInstance(deCH);
> 46: 
> 47:         // i.e. "\u2019" as decimal separator, "\u2019" as grouping separator

This is incorrect (sorry, I am to be blamed as I wrote this ?). Should be "`\u002E` as decimal separator, " also remove `i.e.` if you move the comment on top of the variable declaration

test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 62:

> 60:     // currencySymbolsTest() is only ran for COMPAT
> 61:     private static final boolean isCompat =
> 62:             "COMPAT".equals(System.getProperty("java.locale.providers"));

This check could be moved into `currencySymbolsTest()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350752425
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350835828
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350845412
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350862874
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350883202
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350899278

From redestad at openjdk.org  Mon Oct  9 22:52:10 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Oct 2023 22:52:10 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v17]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: <3Pv5DwaO9rvvx6BX5jWCDkvHoW-tdZDqiilnbvTcGkA=.ad937e13-fc7f-4c97-a6e6-b467a7691011@github.com>

On Mon, 9 Oct 2023 20:40:43 GMT, ???  wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move testcase from BasicInt to Basic-X

test/jdk/java/util/Formatter/Basic-X.java.template line 1748:

> 1746:         // perhaps an IllegalFormatArgumentIndexException should be defined?
> 1747:         tryCatch("%<%", IllegalFormatFlagsException.class);
> 1748: 

After adding test-cases to this template you need to run `genBasic.sh` (in the same folder) to regenerate all the `Basic*` tests. These changes then need to be added to the PR.

FWIW these new and existing tests that provoke `IllegalFormatPrecisionException` and `UnknownFormatConversionException` are common to all types, meaning there seems to be little point in generating them out into each and every `BasicByte`, `BasicInt` et.c.. Perhaps it would make more sense to add such tests directly to Basic.java to avoid some redundancy here - or a new `BasicCommon` test to put common tests into?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1350933399

From jlu at openjdk.org  Mon Oct  9 23:00:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Oct 2023 23:00:08 GMT
Subject: Integrated: JDK-8317633: Modernize text.testlib.HexDumpReader
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 17:19:29 GMT, Justin Lu  wrote:

> Please review this PR which cleans up the static test utility class _HexDumpReader_.
> 
> This cleans up the code by replacing the nested _ByteArrayBuilder_ class with _HexFormat_, and simplifies the File processing by using a stream. Changes were tested to ensure that the _text_ tests are still getting equivalent ByteArrayInputStreams as before.

This pull request has now been integrated.

Changeset: 8e0686b0
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/8e0686b0658eb593bdf36e1c179a4b156fee26bf
Stats:     87 lines in 1 file changed: 12 ins; 58 del; 17 mod

8317633: Modernize text.testlib.HexDumpReader

Reviewed-by: lancea, naoto, mli

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

PR: https://git.openjdk.org/jdk/pull/16075

From duke at openjdk.org  Mon Oct  9 23:21:57 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 23:21:57 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format [v2]
In-Reply-To: 
References: 
Message-ID: 

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

  No longer localize printed numbers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/f40ed1f4..d90111f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=00-01

  Stats: 69 lines in 2 files changed: 41 ins; 22 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16033/head:pull/16033

PR: https://git.openjdk.org/jdk/pull/16033

From duke at openjdk.org  Mon Oct  9 23:34:12 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 9 Oct 2023 23:34:12 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v18]
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
Message-ID: 

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

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

  move testcases to Basic.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/134f2b22..bce554a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=16-17

  Stats: 17 lines in 2 files changed: 11 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15776/head:pull/15776

PR: https://git.openjdk.org/jdk/pull/15776

From mbaesken at openjdk.org  Tue Oct 10 08:13:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Oct 2023 08:13:03 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 9 Oct 2023 15:00:18 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>> 
>> Here is a java callstack of the error situation:
>> test TreeTest.test5(): failure
>> java.lang.AssertionError: expected direct children expected [2] but found [3]
>>         at org.testng.Assert.fail(Assert.java:99)
>>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>>         at org.testng.Assert.assertEquals(Assert.java:122)
>>         at org.testng.Assert.assertEquals(Assert.java:907)
>>         at TreeTest.test5(TreeTest.java:447)
>>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>>         at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>         at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>         at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>         at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>         at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>         at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>         at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>         at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>         at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>>         at org.testng.TestRunner.privateRun(TestRunner.java:764)
>>         at org.testng.TestRunner.run(TestRunner.java:585)
>>         at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>>         at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>>         at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>>         at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>>         at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>>         at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>>       ...
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment

struct procentry64 ProcessBuffer[100];
    pid_t IndexPointer = 0;
    int Chunk = 100;


Hi, do you always want the ProcessBuffer size ==  Chunk  ? If so, why not use a const and also use this const for the size of ProcessBuffer ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1754650903

From coffeys at openjdk.org  Tue Oct 10 08:41:33 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 10 Oct 2023 08:41:33 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key
Message-ID: 

Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

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

Commit messages:
 - Initial changes

Changes: https://git.openjdk.org/jdk/pull/16115/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317678
  Stats: 133 lines in 2 files changed: 131 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From alanb at openjdk.org  Tue Oct 10 08:50:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Oct 2023 08:50:05 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 08:32:28 GMT, Sean Coffey  wrote:

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1424:

> 1422:                             return file.getCanonicalFile();
> 1423:                         } catch (IOException e) {
> 1424:                             throw new RuntimeException(e);

Mapping to RuntimeException doesn't look right here, instead need to use PrivilegedExceptionAction here and changing the Key constructor to throw IOException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1351889427

From alanb at openjdk.org  Tue Oct 10 08:56:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Oct 2023 08:56:57 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 08:32:28 GMT, Sean Coffey  wrote:

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

This is really ZipFile.Source.Key hashCode/equals being inconsistent so I think we should rename the JBS/PR title to make that clearer.

Can you look at the equals method too, need to decide if the checking of lastModifiedTime should be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1754749106
PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1754751022

From prappo at openjdk.org  Tue Oct 10 08:56:59 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 10 Oct 2023 08:56:59 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key
In-Reply-To: 
References: 
Message-ID: <8pCyaUG3A1H4ZMt8TSXjDH8Bai6ihkOf_XkIPDHdA_8=.0daf46f2-a956-4c69-9a7d-18b62034f2d0@github.com>

On Tue, 10 Oct 2023 08:32:28 GMT, Sean Coffey  wrote:

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1444:

> 1442:                 } else {
> 1443:                     return ((int)(t ^ (t >>> 32))) + file.hashCode();
> 1444:                 }

Consider this trivial simplification:
Suggestion:

                Object fk = attrs.fileKey();
                return Long.hashCode(t)
                        + (fk != null ? fk.hashCode() : file.hashCode());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1351918933

From jkern at openjdk.org  Tue Oct 10 09:36:47 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 10 Oct 2023 09:36:47 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v3]
In-Reply-To: 
References: 
Message-ID: 

> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
> 
> Here is a java callstack of the error situation:
> test TreeTest.test5(): failure
> java.lang.AssertionError: expected direct children expected [2] but found [3]
>         at org.testng.Assert.fail(Assert.java:99)
>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>         at org.testng.Assert.assertEquals(Assert.java:122)
>         at org.testng.Assert.assertEquals(Assert.java:907)
>         at TreeTest.test5(TreeTest.java:447)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>         at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>         at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>         at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>         at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>         at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>         at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>         at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>         at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>         at org.testng.TestRunner.privateRun(TestRunner.java:764)
>         at org.testng.TestRunner.run(TestRunner.java:585)
>         at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>         at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>         at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>         at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>         at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>         at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>         at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
>  ...

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  cosmetic changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16051/files
  - new: https://git.openjdk.org/jdk/pull/16051/files/f7b2a47d..5b89bbb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16051&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16051&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16051.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16051/head:pull/16051

PR: https://git.openjdk.org/jdk/pull/16051

From abimpoudis at openjdk.org  Tue Oct 10 09:52:34 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 10 Oct 2023 09:52:34 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v16]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <02ST2uGvMQt4V_x1Yja4iRv9qStRTlPb30RjDRblhBQ=.9e469bd1-fb9d-4cd9-9db3-3bd81aa95837@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Adjust tests
   
   Co-authored-by: Jan Lahoda 
   Co-authored-by: Angelos Bimpoudis 
 - Fix exhaustiveness check for primitive types
 - Add tests
 - Improve non integral check
 - Fixing error conditions, tweaking tests.
 - Attempting to improve reported errors.
 - Add comment for TypePairs
 - Fix Lower.visitTypeTest
 - Merge branch 'master' into primitive-patterns
 - ... and 11 more: https://git.openjdk.org/jdk/compare/5ea9a0ea...3030dc14

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/bab26337..3030dc14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=14-15

  Stats: 5174 lines in 100 files changed: 3529 ins; 943 del; 702 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From liach at openjdk.org  Tue Oct 10 10:22:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Oct 2023 10:22:44 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key
In-Reply-To: 
References: 
Message-ID: <5DuM6mUnnpZJrO2ndsDk4Lk-PCSl__0HJphPPXqJOgI=.eeea1230-59ba-4115-b993-6a4319fed144@github.com>

On Tue, 10 Oct 2023 08:32:28 GMT, Sean Coffey  wrote:

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1418:

> 1416: 
> 1417:             @SuppressWarnings("removal")
> 1418:             private File getCanonicalFile(File file) {

Suggestion:

            private static File getCanonicalFile(File file) {

To avoid this-escape.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1352104428

From redestad at openjdk.org  Tue Oct 10 11:26:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Oct 2023 11:26:41 GMT
Subject: RFR: 8317795: Add an ImmutableBitSetPredicate variant for bitsets <=
 128 elements
Message-ID: 

Alternative to #16082

Name                             (unchanged) Cnt  Base   Error   Test   Error  Unit  Change
URLEncodeDecode.testEncodeLatin1           0  15 2,066 ? 0,104  1,899 ? 0,007 ms/op   1,09x (p = 0,000*)
URLEncodeDecode.testEncodeLatin1          75  15 0,934 ? 0,017  0,811 ? 0,014 ms/op   1,15x (p = 0,000*)
URLEncodeDecode.testEncodeLatin1         100  15 0,433 ? 0,060  0,389 ? 0,007 ms/op   1,11x (p = 0,008*)
  * = significant
  ```

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

Commit messages:
 - Fix and extend ImmutableBitSet test
 - Don't throw IOOBE on negative bitIndexes
 - Handle empty sets
 - Make SmallImmutableBitSetPredicate a record
 - Remove obsolete comment
 - Restore bitIndex < 0 handling
 - Add an ImmutableBitSetPredicate variant for bitsets <= 128 elements

Changes: https://git.openjdk.org/jdk/pull/16094/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16094&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317795
  Stats: 70 lines in 2 files changed: 49 ins; 9 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/16094.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16094/head:pull/16094

PR: https://git.openjdk.org/jdk/pull/16094

From pminborg at openjdk.org  Tue Oct 10 11:26:41 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 10 Oct 2023 11:26:41 GMT
Subject: RFR: 8317795: Add an ImmutableBitSetPredicate variant for bitsets
 <= 128 elements
In-Reply-To: 
References: 
Message-ID: 

On Sun, 8 Oct 2023 21:02:25 GMT, Claes Redestad  wrote:

> Alternative to #16082
> 
> Name                             (unchanged) Cnt  Base   Error   Test   Error  Unit  Change
> URLEncodeDecode.testEncodeLatin1           0  15 2,066 ? 0,104  1,899 ? 0,007 ms/op   1,09x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1          75  15 0,934 ? 0,017  0,811 ? 0,014 ms/op   1,15x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1         100  15 0,433 ? 0,060  0,389 ? 0,007 ms/op   1,11x (p = 0,008*)
>   * = significant
>   ```

Nice improvements.

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

Marked as reviewed by pminborg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16094#pullrequestreview-1666477883

From liach at openjdk.org  Tue Oct 10 11:26:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Oct 2023 11:26:42 GMT
Subject: RFR: 8317795: Add an ImmutableBitSetPredicate variant for bitsets
 <= 128 elements
In-Reply-To: 
References: 
Message-ID: 

On Sun, 8 Oct 2023 21:02:25 GMT, Claes Redestad  wrote:

> Alternative to #16082
> 
> Name                             (unchanged) Cnt  Base   Error   Test   Error  Unit  Change
> URLEncodeDecode.testEncodeLatin1           0  15 2,066 ? 0,104  1,899 ? 0,007 ms/op   1,09x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1          75  15 0,934 ? 0,017  0,811 ? 0,014 ms/op   1,15x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1         100  15 0,433 ? 0,060  0,389 ? 0,007 ms/op   1,11x (p = 0,008*)
>   * = significant
>   ```

src/java.base/share/classes/jdk/internal/util/ImmutableBitSetPredicate.java line 94:

> 92:         private SmallImmutableBitSetPredicate(BitSet original) {
> 93:             // If this class is made public, we need to do
> 94:             // a defensive array copy as certain BitSet implementations

Outdated comments about defensive copy here, as we already copy the longs by value

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16094#discussion_r1349837796

From redestad at openjdk.org  Tue Oct 10 11:26:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Oct 2023 11:26:42 GMT
Subject: RFR: 8317795: Add an ImmutableBitSetPredicate variant for bitsets
 <= 128 elements
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 9 Oct 2023 03:29:38 GMT, Chen Liang  wrote:

>> Alternative to #16082
>> 
>> Name                             (unchanged) Cnt  Base   Error   Test   Error  Unit  Change
>> URLEncodeDecode.testEncodeLatin1           0  15 2,066 ? 0,104  1,899 ? 0,007 ms/op   1,09x (p = 0,000*)
>> URLEncodeDecode.testEncodeLatin1          75  15 0,934 ? 0,017  0,811 ? 0,014 ms/op   1,15x (p = 0,000*)
>> URLEncodeDecode.testEncodeLatin1         100  15 0,433 ? 0,060  0,389 ? 0,007 ms/op   1,11x (p = 0,008*)
>>   * = significant
>>   ```
>
> src/java.base/share/classes/jdk/internal/util/ImmutableBitSetPredicate.java line 94:
> 
>> 92:         private SmallImmutableBitSetPredicate(BitSet original) {
>> 93:             // If this class is made public, we need to do
>> 94:             // a defensive array copy as certain BitSet implementations
> 
> Outdated comments about defensive copy here, as we already copy the longs by value

Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16094#discussion_r1349974627

From asotona at openjdk.org  Tue Oct 10 11:29:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 10 Oct 2023 11:29:40 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v18]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <4aHN-jhUSSm_w8HguRuJ4gPhOJK7ejnH53fVaEAAusg=.c15c43fb-5142-4c85-a15d-a35674f2b3b5@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 348 commits:

 - Merge branch 'master' into JDK-8308753-preview
 - added @sealedGraph tags
 - fixed exception type thrown from CodeImpl
 - added constraint to throw on an attempt to parse unknown classfile version
   + test
 - removed AttributeMapper::validSince
 - fixed DirectCodeBuilder
 - improved ClassFile constants javadoc
 - fixed AnnotationValue::of javadoc
 - fixed elements javadoc
 - Typo in BufWriter javadoc
 - ... and 338 more: https://git.openjdk.org/jdk/compare/ad7a8e86...5e537a86

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=17
  Stats: 32099 lines in 763 files changed: 14605 ins; 14018 del; 3476 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From coffeys at openjdk.org  Tue Oct 10 12:46:22 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 10 Oct 2023 12:46:22 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v2]
In-Reply-To: 
References: 
Message-ID: 

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  incorporate review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/5c3ab873..847d0bd1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=00-01

  Stats: 36 lines in 2 files changed: 8 ins; 16 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From coffeys at openjdk.org  Tue Oct 10 12:49:47 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 10 Oct 2023 12:49:47 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v2]
In-Reply-To: 
References: 
 
Message-ID: <06nlAzdNMQUSt6ha6oh8ZUV5qXQlPNC-ddlut7ZjZFY=.f86e437f-a2e8-4265-86c0-4b8258265744@github.com>

On Tue, 10 Oct 2023 12:46:22 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate review comments

Thanks for the comments to date. I think the latest commit should satisfy requests made.

for `Key.equals(Object)` and `Key.hashCode()` - I've changed the impl so that attrs.lastModifiedTime() is only used in the case where `attrs.fileKey()` returns null. Is that in the direction you were suggesting Alan ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1755350508

From alanb at openjdk.org  Tue Oct 10 12:59:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Oct 2023 12:59:30 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 10 Oct 2023 12:46:22 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporate review comments

src/java.base/share/classes/java/util/zip/ZipFile.java line 1423:

> 1421:                 try {
> 1422:                     return System.getSecurityManager() != null ?
> 1423:                         AccessController.doPrivileged((PrivilegedExceptionAction) file::getCanonicalFile) :

I think you'll have to cleanly separate the SM and no-SM case because of the exception handling, then you can use `PrivilegedExceptionAction pae = file::getCanonicalFile`.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1426:

> 1424:                         file.getCanonicalFile();
> 1425:                 } catch (PrivilegedActionException e) {
> 1426:                     throw new IOException(e);

The IOException to throw is PAE's cause, meaning you need to unwrap.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1451:

> 1449:                     if (!attrs.lastModifiedTime().equals(key.attrs.lastModifiedTime())) {
> 1450:                         return false;
> 1451:                     }

The question in the previous comment is why is the last modified time used here, I think you have to dig into why it is used by equals.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1352471731
PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1352468697
PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1352475053

From rriggs at openjdk.org  Tue Oct 10 13:50:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Oct 2023 13:50:03 GMT
Subject: RFR: 8317795: Add an ImmutableBitSetPredicate variant for bitsets
 <= 128 elements
In-Reply-To: 
References: 
Message-ID: <8leqNjO2tO4YgVGGvdBM8p9ijxmKfCdr784AvCtDSyw=.a37a81c1-99e1-4458-8d61-84bf3e738712@github.com>

On Sun, 8 Oct 2023 21:02:25 GMT, Claes Redestad  wrote:

> Alternative to #16082
> 
> Name                             (unchanged) Cnt  Base   Error   Test   Error  Unit  Change
> URLEncodeDecode.testEncodeLatin1           0  15 2,066 ? 0,104  1,899 ? 0,007 ms/op   1,09x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1          75  15 0,934 ? 0,017  0,811 ? 0,014 ms/op   1,15x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1         100  15 0,433 ? 0,060  0,389 ? 0,007 ms/op   1,11x (p = 0,008*)
>   * = significant
>   ```

Looks good

test/jdk/java/util/BitSet/ImmutableBitSet.java line 65:

> 63:     @Test
> 64:     void basic() {
> 65:         IntStream.of(0, 16, 143, 4711).forEach(k -> basic(k));

A test on either side of the boundary (128) in the implementation might be useful.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16094#pullrequestreview-1667771776
PR Review Comment: https://git.openjdk.org/jdk/pull/16094#discussion_r1352558216

From abimpoudis at openjdk.org  Tue Oct 10 13:58:36 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 10 Oct 2023 13:58:36 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v17]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Update name of exactness methods class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/3030dc14..27c2aab6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=15-16

  Stats: 532 lines in 6 files changed: 285 ins; 242 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From redestad at openjdk.org  Tue Oct 10 14:06:06 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Oct 2023 14:06:06 GMT
Subject: RFR: 8317795: Add an ImmutableBitSetPredicate variant for bitsets
 <= 128 elements [v2]
In-Reply-To: 
References: 
Message-ID: 

> Alternative to #16082
> 
> Name                             (unchanged) Cnt  Base   Error   Test   Error  Unit  Change
> URLEncodeDecode.testEncodeLatin1           0  15 2,066 ? 0,104  1,899 ? 0,007 ms/op   1,09x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1          75  15 0,934 ? 0,017  0,811 ? 0,014 ms/op   1,15x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1         100  15 0,433 ? 0,060  0,389 ? 0,007 ms/op   1,11x (p = 0,008*)
>   * = significant
>   ```

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add test cases, make set sizing more explicit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16094/files
  - new: https://git.openjdk.org/jdk/pull/16094/files/bdcde89d..224053cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16094&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16094&range=00-01

  Stats: 12 lines in 1 file changed: 0 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16094.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16094/head:pull/16094

PR: https://git.openjdk.org/jdk/pull/16094

From redestad at openjdk.org  Tue Oct 10 14:06:07 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Oct 2023 14:06:07 GMT
Subject: RFR: 8317795: Add an ImmutableBitSetPredicate variant for bitsets
 <= 128 elements [v2]
In-Reply-To: <8leqNjO2tO4YgVGGvdBM8p9ijxmKfCdr784AvCtDSyw=.a37a81c1-99e1-4458-8d61-84bf3e738712@github.com>
References: 
 <8leqNjO2tO4YgVGGvdBM8p9ijxmKfCdr784AvCtDSyw=.a37a81c1-99e1-4458-8d61-84bf3e738712@github.com>
Message-ID: 

On Tue, 10 Oct 2023 13:47:07 GMT, Roger Riggs  wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test cases, make set sizing more explicit
>
> test/jdk/java/util/BitSet/ImmutableBitSet.java line 65:
> 
>> 63:     @Test
>> 64:     void basic() {
>> 65:         IntStream.of(0, 16, 143, 4711).forEach(k -> basic(k));
> 
> A test on either side of the boundary (128) in the implementation might be useful.

Thanks for reviewing. I added a few cases and made the `BitSet` creation more explicit w.r.t. size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16094#discussion_r1352576966

From redestad at openjdk.org  Tue Oct 10 14:27:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Oct 2023 14:27:13 GMT
Subject: RFR: 8317795: Add an ImmutableBitSetPredicate variant for bitsets
 <= 128 elements [v3]
In-Reply-To: 
References: 
Message-ID: 

> Alternative to #16082
> 
> Name                             (unchanged) Cnt  Base   Error   Test   Error  Unit  Change
> URLEncodeDecode.testEncodeLatin1           0  15 2,066 ? 0,104  1,899 ? 0,007 ms/op   1,09x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1          75  15 0,934 ? 0,017  0,811 ? 0,014 ms/op   1,15x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1         100  15 0,433 ? 0,060  0,389 ? 0,007 ms/op   1,11x (p = 0,008*)
>   * = significant
>   ```

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add 129, fix erroneous step in clearedAtTheTail

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16094/files
  - new: https://git.openjdk.org/jdk/pull/16094/files/224053cd..e30c03f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16094&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16094&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16094.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16094/head:pull/16094

PR: https://git.openjdk.org/jdk/pull/16094

From liach at openjdk.org  Tue Oct 10 14:49:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Oct 2023 14:49:45 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v18]
In-Reply-To: <4aHN-jhUSSm_w8HguRuJ4gPhOJK7ejnH53fVaEAAusg=.c15c43fb-5142-4c85-a15d-a35674f2b3b5@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <4aHN-jhUSSm_w8HguRuJ4gPhOJK7ejnH53fVaEAAusg=.c15c43fb-5142-4c85-a15d-a35674f2b3b5@github.com>
Message-ID: 

On Tue, 10 Oct 2023 11:29:40 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 348 commits:
> 
>  - Merge branch 'master' into JDK-8308753-preview
>  - added @sealedGraph tags
>  - fixed exception type thrown from CodeImpl
>  - added constraint to throw on an attempt to parse unknown classfile version
>    + test
>  - removed AttributeMapper::validSince
>  - fixed DirectCodeBuilder
>  - improved ClassFile constants javadoc
>  - fixed AnnotationValue::of javadoc
>  - fixed elements javadoc
>  - Typo in BufWriter javadoc
>  - ... and 338 more: https://git.openjdk.org/jdk/compare/ad7a8e86...5e537a86

We need to remove the outdated exports in `BuildMicroBenchmarks.gmk` after the package migration.

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

PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1755601401

From rriggs at openjdk.org  Tue Oct 10 16:40:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Oct 2023 16:40:10 GMT
Subject: RFR: 8317795: Add an ImmutableBitSetPredicate variant for bitsets
 <= 128 elements [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 10 Oct 2023 14:27:13 GMT, Claes Redestad  wrote:

>> Alternative to #16082
>> 
>> Name                             (unchanged) Cnt  Base   Error   Test   Error  Unit  Change
>> URLEncodeDecode.testEncodeLatin1           0  15 2,066 ? 0,104  1,899 ? 0,007 ms/op   1,09x (p = 0,000*)
>> URLEncodeDecode.testEncodeLatin1          75  15 0,934 ? 0,017  0,811 ? 0,014 ms/op   1,15x (p = 0,000*)
>> URLEncodeDecode.testEncodeLatin1         100  15 0,433 ? 0,060  0,389 ? 0,007 ms/op   1,11x (p = 0,008*)
>>   * = significant
>>   ```
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add 129, fix erroneous step in clearedAtTheTail

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16094#pullrequestreview-1668256761

From duke at openjdk.org  Tue Oct 10 16:51:46 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 10 Oct 2023 16:51:46 GMT
Subject: RFR: 8317763: Restrict AVX512 intrinsics for Arrays.sort() methods to
 Intel CPUs
Message-ID: 

The goal of this PR is to restrict the availability of AVX512 accelerated Arrays.sort() methods to only Intel CPUs as a performance regression (due to hardware issues) was reported for AMD Zen4 CPUs in the comments section of #14227.

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

Commit messages:
 - 8317763:Restrict AVX512 intrinsics for Arrays.sort() methods to Intel CPUs

Changes: https://git.openjdk.org/jdk/pull/16124/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16124&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317763
  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16124/head:pull/16124

PR: https://git.openjdk.org/jdk/pull/16124

From redestad at openjdk.org  Tue Oct 10 17:05:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 10 Oct 2023 17:05:22 GMT
Subject: Integrated: 8317795: Add an ImmutableBitSetPredicate variant for
 bitsets <= 128 elements
In-Reply-To: 
References: 
Message-ID: 

On Sun, 8 Oct 2023 21:02:25 GMT, Claes Redestad  wrote:

> Alternative to #16082
> 
> Name                             (unchanged) Cnt  Base   Error   Test   Error  Unit  Change
> URLEncodeDecode.testEncodeLatin1           0  15 2,066 ? 0,104  1,899 ? 0,007 ms/op   1,09x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1          75  15 0,934 ? 0,017  0,811 ? 0,014 ms/op   1,15x (p = 0,000*)
> URLEncodeDecode.testEncodeLatin1         100  15 0,433 ? 0,060  0,389 ? 0,007 ms/op   1,11x (p = 0,008*)
>   * = significant
>   ```

This pull request has now been integrated.

Changeset: 33591a30
Author:    Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/33591a30d2e495b46877b76084aa2f52e5389246
Stats:     70 lines in 2 files changed: 46 ins; 9 del; 15 mod

8317795: Add an ImmutableBitSetPredicate variant for bitsets <= 128 elements

Reviewed-by: pminborg, rriggs

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

PR: https://git.openjdk.org/jdk/pull/16094

From jbhateja at openjdk.org  Tue Oct 10 17:37:09 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Oct 2023 17:37:09 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
In-Reply-To: 
References: 
Message-ID: <4d0seV_zEMsCRCCLpj6WOag2nYDuEK2oi07-P3-exPk=.6e3985ab-9886-42ac-8a2e-e194e87a66db@github.com>

On Tue, 10 Oct 2023 16:44:03 GMT, Srinivas Vamsi Parasa  wrote:

> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
> The proposed changes are:
> 
> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
> 3) Minor changes in Javadoc strings

LGTM

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

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16124#pullrequestreview-1668470152

From kvn at openjdk.org  Tue Oct 10 18:05:10 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 10 Oct 2023 18:05:10 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 16:44:03 GMT, Srinivas Vamsi Parasa  wrote:

> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
> The proposed changes are:
> 
> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
> 3) Minor changes in Javadoc strings

What is change for "Addressing the build failure due to a bug in GCC 12"?

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

> 4174: 
> 4175:   // Load x86_64_sort library on supported hardware to enable avx512 sort and partition intrinsics
> 4176:   if (VM_Version::is_intel() && UseAVX > 2 && VM_Version::supports_avx512dq()) {

I missed this in original changes - you don't need `UseAVX > 2` check here.
We clear avx512dq flag when `UseAVX < 3` : [vm_version_x86.cpp#L939](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L939)

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

PR Review: https://git.openjdk.org/jdk/pull/16124#pullrequestreview-1668504570
PR Review Comment: https://git.openjdk.org/jdk/pull/16124#discussion_r1353067414

From duke at openjdk.org  Tue Oct 10 18:17:11 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 10 Oct 2023 18:17:11 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
In-Reply-To: 
References: 
 
Message-ID: <25G2ipkfOMOkoI6GZ207d8m7FYvN0bL4uC8CXSK-2co=.8fb154ae-bea0-4422-b992-c32a23ffde5f@github.com>

On Tue, 10 Oct 2023 18:01:59 GMT, Vladimir Kozlov  wrote:

> What is change for "Addressing the build failure due to a bug in GCC 12"?

Hello Vladimir,

The change for addressing the build failure will be pushed shortly. 

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1755980823

From duke at openjdk.org  Tue Oct 10 18:46:38 2023
From: duke at openjdk.org (R1chterScale)
Date: Tue, 10 Oct 2023 18:46:38 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 16:44:03 GMT, Srinivas Vamsi Parasa  wrote:

> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
> The proposed changes are:
> 
> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
> 3) Minor changes in Javadoc strings

Forgive me, I might be missing something very obvious, but is there any particular reason to entirely disable the SIMD accelerated sort on Zen 4 rather than having an alternate code path for Zen 4 where it has the `compressstoreu` instructions split up into separate `compress` and `storeu` instructions so that Zen 4 platforms can still benefit from a decent degree of performance uplift from AVX512 acceleration of sort?

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756020209

From duke at openjdk.org  Tue Oct 10 19:03:42 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 10 Oct 2023 19:03:42 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: 
References: 
Message-ID: <7uQXiY0QakPb2mrMiU3fXXOEcqamb34Q6atD0ZJ8ReE=.4dad0f4b-8e7c-430d-b6cf-370db71927ae@github.com>

> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
> The proposed changes are:
> 
> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
> 3) Minor changes in Javadoc strings

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  pragma workround for GCC12 bug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16124/files
  - new: https://git.openjdk.org/jdk/pull/16124/files/1138dc38..386bdd88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16124&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16124&range=00-01

  Stats: 12 lines in 2 files changed: 10 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16124/head:pull/16124

PR: https://git.openjdk.org/jdk/pull/16124

From duke at openjdk.org  Tue Oct 10 19:03:42 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 10 Oct 2023 19:03:42 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 10 Oct 2023 17:55:43 GMT, Vladimir Kozlov  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   pragma workround for GCC12 bug
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4176:
> 
>> 4174: 
>> 4175:   // Load x86_64_sort library on supported hardware to enable avx512 sort and partition intrinsics
>> 4176:   if (VM_Version::is_intel() && UseAVX > 2 && VM_Version::supports_avx512dq()) {
> 
> I missed this in original changes - you don't need `UseAVX > 2` check here.
> We clear avx512dq flag when `UseAVX < 3` : [vm_version_x86.cpp#L939](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L939)

Please see this fixed in the latest commit pushed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16124#discussion_r1353147697

From duke at openjdk.org  Tue Oct 10 19:04:58 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 10 Oct 2023 19:04:58 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 10 Oct 2023 18:01:59 GMT, Vladimir Kozlov  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   pragma workround for GCC12 bug
>
> What is change for "Addressing the build failure due to a bug in GCC 12"?

Hello Vladimir (@vnkozlov) and Erik (@erikj79),

Please see the latest commit which has the `#pragma` based workaround to address the build failure caused by GCC 12.

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756046292

From duke at openjdk.org  Tue Oct 10 20:21:56 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 10 Oct 2023 20:21:56 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: 
References: 
Message-ID: <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>

> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
> The proposed changes are:
> 
> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
> 3) Minor changes in Javadoc strings

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  fix whitespace in build script

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16124/files
  - new: https://git.openjdk.org/jdk/pull/16124/files/386bdd88..a565f1d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16124&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16124&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16124/head:pull/16124

PR: https://git.openjdk.org/jdk/pull/16124

From ihse at openjdk.org  Tue Oct 10 20:21:56 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Oct 2023 20:21:56 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: <7uQXiY0QakPb2mrMiU3fXXOEcqamb34Q6atD0ZJ8ReE=.4dad0f4b-8e7c-430d-b6cf-370db71927ae@github.com>
References: 
 <7uQXiY0QakPb2mrMiU3fXXOEcqamb34Q6atD0ZJ8ReE=.4dad0f4b-8e7c-430d-b6cf-370db71927ae@github.com>
Message-ID: 

On Tue, 10 Oct 2023 19:03:42 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pragma workround for GCC12 bug

In #14227, you inadvertently added an extra space at line 230 in make/modules/java.base/Lib.gmk
(https://github.com/openjdk/jdk/pull/14227/files#diff-c2e113e4b2661697750fd5e6dcc0908fa98563ccfb3801c8b0e3a70174041b81).

Can you please revert it here?

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756121760

From duke at openjdk.org  Tue Oct 10 20:21:56 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 10 Oct 2023 20:21:56 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: 
References: 
 <7uQXiY0QakPb2mrMiU3fXXOEcqamb34Q6atD0ZJ8ReE=.4dad0f4b-8e7c-430d-b6cf-370db71927ae@github.com>
 
Message-ID: 

On Tue, 10 Oct 2023 19:48:50 GMT, Magnus Ihse Bursie  wrote:

> In #14227, you inadvertently added an extra space at line 230 in make/modules/java.base/Lib.gmk 

Hi Magnus (@magicus), please see the extra space fixed in the latest commit.

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756143139

From rriggs at openjdk.org  Tue Oct 10 20:32:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Oct 2023 20:32:03 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 10 Oct 2023 09:36:47 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>> 
>> Here is a java callstack of the error situation:
>> test TreeTest.test5(): failure
>> java.lang.AssertionError: expected direct children expected [2] but found [3]
>>         at org.testng.Assert.fail(Assert.java:99)
>>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>>         at org.testng.Assert.assertEquals(Assert.java:122)
>>         at org.testng.Assert.assertEquals(Assert.java:907)
>>         at TreeTest.test5(TreeTest.java:447)
>>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>>         at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
>>         at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
>>         at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
>>         at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
>>         at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
>>         at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
>>         at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
>>         at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
>>         at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>>         at org.testng.TestRunner.privateRun(TestRunner.java:764)
>>         at org.testng.TestRunner.run(TestRunner.java:585)
>>         at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
>>         at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
>>         at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
>>         at org.testng.SuiteRunner.run(SuiteRunner.java:286)
>>         at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
>>         at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
>>       ...
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

The full stack trace doesn't add any value in the PR description and makes every email on the subject too long.
If its in the issue, it doesn't need to be here.  $0.02, Roger

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 85:

> 83:     const int Chunk = 100;
> 84:     struct procentry64 ProcessBuffer[Chunk];
> 85:     pid_t IndexPointer = 0;

Initial capital 'I' is unusual for a local variable.

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 106:

> 104:         }
> 105: 
> 106:         while ((num = getprocs64(ProcessBuffer, sizeof(struct procentry64), NULL, sizeof(struct fdsinfo64), &IndexPointer, Chunk)) != -1) {

Please line break somewhere between 80-100.

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 108:

> 106:         while ((num = getprocs64(ProcessBuffer, sizeof(struct procentry64), NULL, sizeof(struct fdsinfo64), &IndexPointer, Chunk)) != -1) {
> 107:           for (i = 0; i < num; i++) {
> 108:             pid_t ppid = 0;

Indentation should be 4 for core-libs native files.

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 138:

> 136:           }
> 137:           if (num < Chunk)
> 138:             break;

indent = 4
The style (in this file) after `if` is to use braces.

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 155:

> 153:       JNU_ThrowByNameWithLastError(env,
> 154:           "java/lang/RuntimeException", "Unable to retrieve Process info");
> 155:       return -1;

Identation = 4

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1756094157
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1353220388
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1353209896
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1353211188
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1353214079
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1353216706

From duke at openjdk.org  Tue Oct 10 20:32:02 2023
From: duke at openjdk.org (iaroslavski)
Date: Tue, 10 Oct 2023 20:32:02 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: 
References: 
 <7uQXiY0QakPb2mrMiU3fXXOEcqamb34Q6atD0ZJ8ReE=.4dad0f4b-8e7c-430d-b6cf-370db71927ae@github.com>
 
 
Message-ID: 

On Tue, 10 Oct 2023 20:04:48 GMT, Srinivas Vamsi Parasa  wrote:

>> In #14227, you inadvertently added an extra space at line 230 in make/modules/java.base/Lib.gmk
>> (https://github.com/openjdk/jdk/pull/14227/files#diff-c2e113e4b2661697750fd5e6dcc0908fa98563ccfb3801c8b0e3a70174041b81).
>> 
>> Can you please revert it here?
>
>> In #14227, you inadvertently added an extra space at line 230 in make/modules/java.base/Lib.gmk 
> 
> Hi Magnus (@magicus), please see the extra space fixed in the latest commit.
> 
> Thanks,
> Vamsi

Hi @vamsi-parasa ,

Methods `partitionDualPivot` and `partitionSinglePivot` are annotated by @ForceInline, but
`mixedInsertionSort` and `insertionSort` are not. These all 4 methods are passed as parameter 
to methods `private static  int[] partition(Class elemType, A array, ...`
and `private static  void sort(Class elemType, A array, ...`.

Is ok that `partitionDualPivot`, `partitionSinglePivot` and `mixedInsertionSort`, `insertionSort` are annotated differently?

Should we add @ForceInline to `mixedInsertionSort`, `insertionSort` or
remove @ForceInline from `partitionDualPivot` and `partitionSinglePivot`?

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756156620

From jvernee at openjdk.org  Tue Oct 10 21:04:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 10 Oct 2023 21:04:24 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v35]
In-Reply-To: 
References: 
Message-ID: 

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/b4a7b7ab..35ca1921

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=33-34

  Stats: 107 lines in 107 files changed: 0 ins; 0 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

PR: https://git.openjdk.org/jdk/pull/15103

From rriggs at openjdk.org  Tue Oct 10 21:46:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 10 Oct 2023 21:46:12 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format [v2]
In-Reply-To: 
References: 
 
Message-ID: <-N0BCuO7PgyYu22RIIqyWZlP9WqopFknnmHBWP5OSYA=.5a8c392e-01ff-4bc6-9780-67d0eb09818b@github.com>

On Mon, 9 Oct 2023 23:21:57 GMT, Shaojin Wen  wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No longer localize printed numbers

The template in the CSR has sections for: Summary, Problem, Solution, and Specification and a separate section for a prose description of the compatibility risk.
Please recompose the CSR content to fit those sections.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1756310877

From kvn at openjdk.org  Tue Oct 10 22:08:31 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 10 Oct 2023 22:08:31 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: 
References: 
 <7uQXiY0QakPb2mrMiU3fXXOEcqamb34Q6atD0ZJ8ReE=.4dad0f4b-8e7c-430d-b6cf-370db71927ae@github.com>
 
 
 
Message-ID: 

On Tue, 10 Oct 2023 20:14:51 GMT, iaroslavski  wrote:

> Is ok that partitionDualPivot, partitionSinglePivot and mixedInsertionSort, insertionSort are annotated differently?

Good question. Someone familiar with this Java code should answer.

Note,  **@forceinline** annotation is used by C2 JIT compiler when it decide to inline. One criteria is the bytecode size (we don't want inline huge method into another compilation). Default value is 35. With **@forceinline** the size will be **1** - most likely guarantee inlining.
But there is drawback, if java method is not "hot" (not called frequently) the inlined code may lead to not optimal code generation.
Use it carefully.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756334136

From kvn at openjdk.org  Tue Oct 10 22:32:42 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 10 Oct 2023 22:32:42 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
Message-ID: 

On Tue, 10 Oct 2023 20:21:56 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix whitespace in build script

Also @forceinline in these changes only works for case when new intrinsics are not used.
I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics.
That will tell us which @forceinline annotations are needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756356272

From jvernee at openjdk.org  Tue Oct 10 23:17:17 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 10 Oct 2023 23:17:17 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v36]
In-Reply-To: 
References: 
Message-ID: 

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  adjust misformatted copyright headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/35ca1921..5cf9e753

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=34-35

  Stats: 66 lines in 4 files changed: 0 ins; 0 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

PR: https://git.openjdk.org/jdk/pull/15103

From bpb at openjdk.org  Tue Oct 10 23:29:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Oct 2023 23:29:40 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory
Message-ID: 

Change test to use `RandomFactory` instead of `new Random()` and convert it to JUnit 5.

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

Commit messages:
 - 8313621: Convert test to JUnit 5
 - 8313621: test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use RandomFactory

Changes: https://git.openjdk.org/jdk/pull/16130/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313621
  Stats: 118 lines in 1 file changed: 11 ins; 78 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/16130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16130/head:pull/16130

PR: https://git.openjdk.org/jdk/pull/16130

From smarks at openjdk.org  Wed Oct 11 02:38:04 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 11 Oct 2023 02:38:04 GMT
Subject: RFR: 8314896: additional clarifications to reversed() default
 methods' implementation requirements [v2]
In-Reply-To: 
References: 
Message-ID: <0DhTJXQ8h1dfJjgw9ntNGM3lFIKiSU4HhpvO3Kzfopg=.46107527-99da-493e-98a9-1b44fa16904a@github.com>

> Wording changes to make clear that the scenarios described are merely examples and are not normative requirements.

Stuart Marks has updated the pull request with a new target base 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-8314896-more-reversed-clarifications
 - Update wording for {Deque,List,SortedMap,SortedSet}.reversed implSpecs.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15799/files
  - new: https://git.openjdk.org/jdk/pull/15799/files/064bc649..f88d0cba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15799&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15799&range=00-01

  Stats: 95017 lines in 2630 files changed: 38584 ins; 18471 del; 37962 mod
  Patch: https://git.openjdk.org/jdk/pull/15799.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15799/head:pull/15799

PR: https://git.openjdk.org/jdk/pull/15799

From duke at openjdk.org  Wed Oct 11 04:13:35 2023
From: duke at openjdk.org (ANUPAM DEV)
Date: Wed, 11 Oct 2023 04:13:35 GMT
Subject: RFR: 8317846: Typo in API documentation of classes IdentityHashMap
Message-ID: 

Hello,

I have fixed the typo in the comment for the constructor IdentityHashMap(Map m) 

before: Constructs a new identity hash map containing the keys-value mappings in the specified map.
after: Constructs a new identity hash map containing the key-value mappings in the specified map.

Please review the change.

Regards,
Anupam

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

Commit messages:
 - 8317846: Typo in API documentation of classes IdentityHashMap
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge pull request #1 from anupamdev20/JDK-8255675
 - 8255675: Typo in java.net.HttpURLConnection

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

PR: https://git.openjdk.org/jdk/pull/16132

From duke at openjdk.org  Wed Oct 11 04:29:23 2023
From: duke at openjdk.org (ANUPAM DEV)
Date: Wed, 11 Oct 2023 04:29:23 GMT
Subject: RFR: 8317846: Typo in API documentation of classes IdentityHashMap
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 Oct 2023 04:05:48 GMT, ANUPAM DEV  wrote:

> Hello,
> 
> I have fixed the typo in the comment for the constructor IdentityHashMap(Map m) 
> 
> before: Constructs a new identity hash map containing the keys-value mappings in the specified map.
> after: Constructs a new identity hash map containing the key-value mappings in the specified map.
> 
> Please review the change.
> 
> Regards,
> Anupam

The checks were failing

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

PR Comment: https://git.openjdk.org/jdk/pull/16132#issuecomment-1756760760

From duke at openjdk.org  Wed Oct 11 04:29:23 2023
From: duke at openjdk.org (ANUPAM DEV)
Date: Wed, 11 Oct 2023 04:29:23 GMT
Subject: Withdrawn: 8317846: Typo in API documentation of classes
 IdentityHashMap
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 Oct 2023 04:05:48 GMT, ANUPAM DEV  wrote:

> Hello,
> 
> I have fixed the typo in the comment for the constructor IdentityHashMap(Map m) 
> 
> before: Constructs a new identity hash map containing the keys-value mappings in the specified map.
> after: Constructs a new identity hash map containing the key-value mappings in the specified map.
> 
> Please review the change.
> 
> Regards,
> Anupam

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/16132

From duke at openjdk.org  Wed Oct 11 05:01:31 2023
From: duke at openjdk.org (ANUPAM DEV)
Date: Wed, 11 Oct 2023 05:01:31 GMT
Subject: RFR: 8317846: Typo in API documentation of classes IdentityHashMap
Message-ID: 

Hello,

I have fixed the typo in the comment for the constructor IdentityHashMap(Map m)

before: Constructs a new identity hash map containing the keys-value mappings in the specified map.
after: Constructs a new identity hash map containing the key-value mappings in the specified map.

Please review the change.

Regards,
Anupam

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

Commit messages:
 - Updated comment in the constructor IdentityHashMap(Map m)

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

PR: https://git.openjdk.org/jdk/pull/16134

From duke at openjdk.org  Wed Oct 11 05:29:22 2023
From: duke at openjdk.org (ANUPAM DEV)
Date: Wed, 11 Oct 2023 05:29:22 GMT
Subject: RFR: 8317846: Typo in API documentation of classes IdentityHashMap
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hello,
> 
> I have fixed the typo in the comment for the constructor IdentityHashMap(Map m)
> 
> before: Constructs a new identity hash map containing the keys-value mappings in the specified map.
> after: Constructs a new identity hash map containing the key-value mappings in the specified map.
> 
> Please review the change.
> 
> Regards,
> Anupam

ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision:

  Reverted the Copyright year to 2022

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16134/files
  - new: https://git.openjdk.org/jdk/pull/16134/files/134e8d7f..62493559

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16134&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16134&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16134/head:pull/16134

PR: https://git.openjdk.org/jdk/pull/16134

From asotona at openjdk.org  Wed Oct 11 06:33:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Oct 2023 06:33:57 GMT
Subject: RFR: 8317609: Classfile API fails to verify
 /jdk.jcmd/sun/tools/jstat/Alignment.class
Message-ID: 

JImageValidator has been recently converted to use ClassFile API and original weak validation of class files was replaced with full class verification.
Unfortunately full class verification is too strong as it includes class assignability verification according to class hierarchy resolution.
This patch relaxes class assignability verification from JImageValidator by mocking ClassHierarchyResolver.
Resolution of all classes as interfaces during verification effectively cancels the assignability verification (as interface assignability is not verified).

Please review this pull request.

Thanks,
Adam

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

Commit messages:
 - 8317609: Classfile API fails to verify /jdk.jcmd/sun/tools/jstat/Alignment.class

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

PR: https://git.openjdk.org/jdk/pull/16123

From liach at openjdk.org  Wed Oct 11 06:33:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 11 Oct 2023 06:33:58 GMT
Subject: RFR: 8317609: Classfile API fails to verify
 /jdk.jcmd/sun/tools/jstat/Alignment.class
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 15:09:41 GMT, Adam Sotona  wrote:

> JImageValidator has been recently converted to use ClassFile API and original weak validation of class files was replaced with full class verification.
> Unfortunately full class verification is too strong as it includes class assignability verification according to class hierarchy resolution.
> This patch relaxes class assignability verification from JImageValidator by mocking ClassHierarchyResolver.
> Resolution of all classes as interfaces during verification effectively cancels the assignability verification (as interface assignability is not verified).
> 
> Please review this pull request.
> 
> Thanks,
> Adam

On a side note, it seems weird that you need to pass a CHR again for verification instead of reusing the one from Class-File context object. Maybe we can consider moving verify to Class-File object for a new RFE?

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/16123#pullrequestreview-1669984629

From asotona at openjdk.org  Wed Oct 11 06:33:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Oct 2023 06:33:58 GMT
Subject: RFR: 8317609: Classfile API fails to verify
 /jdk.jcmd/sun/tools/jstat/Alignment.class
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 05:44:42 GMT, Chen Liang  wrote:

> Maybe we can consider moving verify to Class-File object for a new RFE?

Yes, that would be appropriate.

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

PR Comment: https://git.openjdk.org/jdk/pull/16123#issuecomment-1756874646

From duke at openjdk.org  Wed Oct 11 07:03:26 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 11 Oct 2023 07:03:26 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: 
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
 
Message-ID: 

On Tue, 10 Oct 2023 22:29:55 GMT, Vladimir Kozlov  wrote:

> Also @forceinline in these changes only works for case when new intrinsics are not used. I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics. That will tell us which @forceinline annotations are needed.

@vnkozlov Thank you for explanation, I will benchmark cases with and without @forceinline and provide results very soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756972805

From duke at openjdk.org  Wed Oct 11 07:06:22 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 11 Oct 2023 07:06:22 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: 
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
 
Message-ID: 

On Tue, 10 Oct 2023 22:29:55 GMT, Vladimir Kozlov  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix whitespace in build script
>
> Also @forceinline in these changes only works for case when new intrinsics are not used.
> I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics.
> That will tell us which @forceinline annotations are needed.

@vnkozlov 
Are there any options to be sure that C2 JIT compiler is used during tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756979089

From duke at openjdk.org  Wed Oct 11 07:14:10 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 11 Oct 2023 07:14:10 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: 
References: 
 <7uQXiY0QakPb2mrMiU3fXXOEcqamb34Q6atD0ZJ8ReE=.4dad0f4b-8e7c-430d-b6cf-370db71927ae@github.com>
 
 
Message-ID: 

On Tue, 10 Oct 2023 20:04:48 GMT, Srinivas Vamsi Parasa  wrote:

>> In #14227, you inadvertently added an extra space at line 230 in make/modules/java.base/Lib.gmk
>> (https://github.com/openjdk/jdk/pull/14227/files#diff-c2e113e4b2661697750fd5e6dcc0908fa98563ccfb3801c8b0e3a70174041b81).
>> 
>> Can you please revert it here?
>
>> In #14227, you inadvertently added an extra space at line 230 in make/modules/java.base/Lib.gmk 
> 
> Hi Magnus (@magicus), please see the extra space fixed in the latest commit.
> 
> Thanks,
> Vamsi

Hi @vamsi-parasa,

Both methods mixedInsertionSort and insertionSort are covered by intrinsics.
But insertionSort is run on leftmnost (one) part only and on small ( < MAX_INSERTION_SORT_SIZE = 44) arrays.
Do we actually need to use intrinsics for it?

To have clear picture could you please run benchmarking to compare both cases:
current implementation and implementation with Java insertionSort only?

see changes `sort(int.class, a, Unsafe.ARRAY_INT_BASE_OFFSET, low, high, DualPivotQuicksort::insertionSort);`
->
`insertionSort(a, low, high);`

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1756991305

From asotona at openjdk.org  Wed Oct 11 07:17:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Oct 2023 07:17:04 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed obsolete exports from BuildMicrobenchmark.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/5e537a86..37371955

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=17-18

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Wed Oct 11 07:17:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Oct 2023 07:17:38 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v18]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <4aHN-jhUSSm_w8HguRuJ4gPhOJK7ejnH53fVaEAAusg=.c15c43fb-5142-4c85-a15d-a35674f2b3b5@github.com>
 
Message-ID: 

On Tue, 10 Oct 2023 14:46:32 GMT, Chen Liang  wrote:

> We need to remove the outdated exports in `BuildMicroBenchmarks.gmk` after the package migration.

Removed, good catch, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1756993662

From pminborg at openjdk.org  Wed Oct 11 07:53:24 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 07:53:24 GMT
Subject: RFR: 8317868: Add @sealedGraph to MethodHandleDesc and descendants
Message-ID: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>

This PR proposes to add  @sealedGraph to MethodHandleDesc and descendants.

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

Commit messages:
 - Add @sealedGraph to MethodHandleDesc and descendants

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

PR: https://git.openjdk.org/jdk/pull/16137

From pminborg at openjdk.org  Wed Oct 11 07:59:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 07:59:49 GMT
Subject: RFR: 8317870: Add @sealedGraph to Thread.Builder
Message-ID: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>

This PR proposes to Add @sealedGraph to `Thread.Builder`.

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

Commit messages:
 - Add @sealedGraph to Thread.Builder

Changes: https://git.openjdk.org/jdk/pull/16138/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16138&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317870
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16138.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16138/head:pull/16138

PR: https://git.openjdk.org/jdk/pull/16138

From liach at openjdk.org  Wed Oct 11 08:00:02 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 11 Oct 2023 08:00:02 GMT
Subject: RFR: 8317868: Add @sealedGraph to MethodHandleDesc and descendants
In-Reply-To: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
References: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
Message-ID: 

On Wed, 11 Oct 2023 07:45:17 GMT, Per Minborg  wrote:

> This PR proposes to add  @sealedGraph to MethodHandleDesc and descendants.

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

> 47:  * a {@code Constant_MethodHandle_info} entry in the constant pool of a classfile.
> 48:  *
> 49:  * @sealedGraph

DMH desc has no public implementation subtypes. A `@sealedGraph` would probably just render a single root node, which is not informative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16137#discussion_r1354341911

From pminborg at openjdk.org  Wed Oct 11 08:07:58 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 08:07:58 GMT
Subject: RFR: 8317873: Add @sealedGraph to IllegalFormatException
Message-ID: 

This PR proposes to add @sealedGraph to `IllegalFormatException`

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

Commit messages:
 - Add @sealedGraph to IllegalFormatException

Changes: https://git.openjdk.org/jdk/pull/16140/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16140&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317873
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16140/head:pull/16140

PR: https://git.openjdk.org/jdk/pull/16140

From abimpoudis at openjdk.org  Wed Oct 11 08:09:03 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 11 Oct 2023 08:09:03 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v18]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Update name of exactness methods class
 - Merge branch 'master' into primitive-patterns
 - Adjust tests
   
   Co-authored-by: Jan Lahoda 
   Co-authored-by: Angelos Bimpoudis 
 - Fix exhaustiveness check for primitive types
 - Add tests
 - Improve non integral check
 - Fixing error conditions, tweaking tests.
 - Attempting to improve reported errors.
 - Add comment for TypePairs
 - ... and 13 more: https://git.openjdk.org/jdk/compare/68beac56...3c0d85e9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/27c2aab6..3c0d85e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=16-17

  Stats: 1754 lines in 30 files changed: 800 ins; 788 del; 166 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From pminborg at openjdk.org  Wed Oct 11 08:23:53 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 08:23:53 GMT
Subject: RFR: 8317874: Add @sealedGraph to StringTemplate.Processor.Linkage
Message-ID: 

This PR proposes to Add @sealedGraph to `StringTemplate.Processor.Linkage`

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

Commit messages:
 - Add @sealedGraph to StringTemplate.Processor.Linkage

Changes: https://git.openjdk.org/jdk/pull/16141/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16141&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317874
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16141/head:pull/16141

PR: https://git.openjdk.org/jdk/pull/16141

From prappo at openjdk.org  Wed Oct 11 08:35:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 11 Oct 2023 08:35:14 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: 
References: 
Message-ID: <3wBL3OUSuhV06a9A7vUxe-udkndpaFR7ve-BQystcj8=.07022c6f-99e8-4d78-bf99-98b8b092d175@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo  wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

To Skara bots: keep this PR alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1757125826

From prappo at openjdk.org  Wed Oct 11 08:35:18 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 11 Oct 2023 08:35:18 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v7]
In-Reply-To: 
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 
Message-ID: 

On Tue, 19 Sep 2023 09:49:53 GMT, Pavel Rappo  wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8310813
>  - Fix bugs in Shared.createSingle
>  - Merge branch 'master' into 8310813
>  - Group params coarser (suggested by @cl4es)
>    
>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>      Every testXYZ method invokes M operations, where M is the maximum
>      number of elements in a group. Shorter groups are cyclically padded.
>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>      benchmark time.
>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>  - Use better overloads (suggested by @cl4es)
>    
>    - Uses simpler, more suitable overloads for the subrange
>      starting from 0
>  - Improve benchmarks
>  - Merge branch 'master' into 8310813
>  - Restore hash code values
>    
>    BigInteger is old and ubiquitous enough so that there might be
>    inadvertent dependencies on its hash code.
>    
>    This commit also includes a test, to make sure hash code is
>    unchanged.
>  - Merge branch 'master' into 8310813
>  - Add a benchmark
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/0764977c...77bfab34

To Skara bots: keep this PR alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1757127884

From aph at openjdk.org  Wed Oct 11 09:28:17 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 11 Oct 2023 09:28:17 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
In-Reply-To: 
References: 
 
Message-ID: <-IoxCx93JQjLWexw1E3PvX---kjb9yDiojjVVML5Has=.ae198edf-9a1c-4ee3-ba51-166887d0ae96@github.com>

On Tue, 10 Oct 2023 18:40:30 GMT, R1chterScale  wrote:

> Forgive me, I might be missing something very obvious, but is there any particular reason to entirely disable the SIMD accelerated sort on Zen 4 rather than having an alternate code path for Zen 4 where it has the `compressstoreu` instructions split up into separate `compress` and `storeu` instructions so that Zen 4 platforms can still benefit from a decent degree of performance uplift from AVX512 acceleration of sort?

I don't think you're missing anything. This should be done, rather than disabling the intrinsic.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1757248773

From redestad at openjdk.org  Wed Oct 11 09:53:19 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 11 Oct 2023 09:53:19 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v2]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Mon, 9 Oct 2023 19:20:29 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor based on @liach 's review

I'm not really qualified to review the floating point code. Simplifying away offset and getting rid of the StringBuilderHelper all seem like good improvements, though I think it'd be good if we could either avoid or split out the `JLA` changes.

src/java.base/share/classes/java/lang/System.java line 2548:

> 2546: 
> 2547:             public int stringSize(int i) {
> 2548:                 return Long.stringSize(i);

Shouldn't this be `return Integer.stringSize(i);`?

src/java.base/share/classes/java/math/BigDecimal.java line 4168:

> 4166:             int lowInt = (int)intCompact % 100;
> 4167:             int highInt = (int)intCompact / 100;
> 4168:             int highIntSize = JLA.stringSize(highInt);

Which micros cover performance of this branch?

What performance would you get if you simplified this to, say, `return highInt + (lowInt < 10 ? ".0" : ".") + lowInt;`?

`lowInt` is currently unused since you use `(int) intCompact - highInt * 100` instead below. (While a clever optimization in theory, I believe the JIT should handle a pair of integer modulo and division operations (`a = intValue % 100; b = intValue / 100`) so that it only has to do one division, so please measure that whatever you do here has a significant benefit).

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

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16006#pullrequestreview-1668452019
PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1353035743
PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1354592018

From rgiulietti at openjdk.org  Wed Oct 11 10:30:10 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Oct 2023 10:30:10 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 23:21:42 GMT, Brian Burkhalter  wrote:

> Change test to use `RandomFactory` instead of `new Random()` and convert it to JUnit 5.

test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal.java line 115:

> 113:         }
> 114: 
> 115:         assertTrue(failures == 0);

Suggestion:

        assertEquals(0, failures);

Gives a better message because it explicitly knows both the expected value (1st arg) and the actual value (2nd arg).
Similarly for other `assertTrue` usages below).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16130#discussion_r1354633701

From jkern at openjdk.org  Wed Oct 11 10:57:24 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 11 Oct 2023 10:57:24 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
Message-ID: 

> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  cosmetic changes 2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16051/files
  - new: https://git.openjdk.org/jdk/pull/16051/files/5b89bbb4..986ff9a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16051&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16051&range=02-03

  Stats: 37 lines in 1 file changed: 3 ins; 1 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/16051.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16051/head:pull/16051

PR: https://git.openjdk.org/jdk/pull/16051

From jkern at openjdk.org  Wed Oct 11 10:57:25 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 11 Oct 2023 10:57:25 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 10 Oct 2023 09:36:47 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes

I followed Rogers proposals.

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1757400941

From pminborg at openjdk.org  Wed Oct 11 11:18:41 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 11:18:41 GMT
Subject: RFR: 8317868: Add @sealedGraph to MethodHandleDesc and descendants
 [v2]
In-Reply-To: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
References: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
Message-ID: 

> This PR proposes to add  @sealedGraph to MethodHandleDesc and descendants.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year
 - Revoke change in DMHD

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16137/files
  - new: https://git.openjdk.org/jdk/pull/16137/files/dd6d4103..dc368d77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16137&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16137&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16137/head:pull/16137

PR: https://git.openjdk.org/jdk/pull/16137

From pminborg at openjdk.org  Wed Oct 11 11:18:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 11:18:45 GMT
Subject: RFR: 8317868: Add @sealedGraph to MethodHandleDesc and descendants
 [v2]
In-Reply-To: 
References: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
 
Message-ID: <23SzfjmJpEuKds_6iUswmvRQMCUbcgRT7A3xxS7KCCg=.f919f669-f5ea-43f4-aa42-780e0847806c@github.com>

On Wed, 11 Oct 2023 07:57:11 GMT, Chen Liang  wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>  - Revoke change in DMHD
>
> src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java line 49:
> 
>> 47:  * a {@code Constant_MethodHandle_info} entry in the constant pool of a classfile.
>> 48:  *
>> 49:  * @sealedGraph
> 
> DMH desc has no public implementation subtypes. A `@sealedGraph` would probably just render a single root node, which is not informative.

Well spotted. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16137#discussion_r1354763919

From mbaesken at openjdk.org  Wed Oct 11 11:19:09 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Oct 2023 11:19:09 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 10:57:24 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes 2

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 1:

> 1: /*

Maybe better just assign the starttime when  it is needed 
`stimes[count] = ((jlong) ProcessBuffer[i].pi_start) *1000;`
and avoid 2 lines of variable declaration and assignment ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1354778759

From stuefe at openjdk.org  Wed Oct 11 11:27:10 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 11 Oct 2023 11:27:10 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 10:57:24 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes 2

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 43:

> 41: /*
> 42:  * Returns the children of the requested pid and optionally each parent and
> 43:  * start time. If requested pid is zero return all processes.

This deserves at least a better explanation, because I was first wondering why you return the parent pid since that would be just, well, the pid. Then I thought "oh, maybe he traverses indirect children too, then returning the respective parent pid would make sense". And then I saw that no, you only return direct children *unless* pid is 0. So the parent pid business makes only sense for the pid==0 case.

So, from looking at the implementation, the only point of the parent pid return array is if you pass in 0 as pid. This should be made clearer. Or even better, split this into two functions, one "get children(pid, returnpidarray)" and one "getAllProcesses(returnarray, ppid returnarray)".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1354791604

From ihse at openjdk.org  Wed Oct 11 11:36:09 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Oct 2023 11:36:09 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
Message-ID: 

On Tue, 10 Oct 2023 20:21:56 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix whitespace in build script

Build changes look good. Thanks for fixing this!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16124#pullrequestreview-1670939988

From jkern at openjdk.org  Wed Oct 11 12:10:12 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 11 Oct 2023 12:10:12 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 11 Oct 2023 11:22:21 GMT, Thomas Stuefe  wrote:

>> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cosmetic changes 2
>
> src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 43:
> 
>> 41: /*
>> 42:  * Returns the children of the requested pid and optionally each parent and
>> 43:  * start time. If requested pid is zero return all processes.
> 
> This deserves at least a better explanation, because I was first wondering why you return the parent pid since that would be just, well, the pid. Then I thought "oh, maybe he traverses indirect children too, then returning the respective parent pid would make sense". And then I saw that no, you only return direct children *unless* pid is 0. So the parent pid business makes only sense for the pid==0 case.
> 
> So, from looking at the implementation, the only point of the parent pid return array is if you pass in 0 as pid. This should be made clearer. Or even better, split this into two functions, one "get children(pid, returnpidarray)" and one "getAllProcesses(returnarray, ppid returnarray)".

Hi Thomas, this function is just the same as the linux and macos implementation. And I do not want to make more changes as really needed, otherwise the siblings character gets lost. Following your proposal means to do the split for linux and macos too. And to be honest, I do not really know the intention of the function, maybe the implementation is wrong on all platforms. So my goal was to only exchange the used API and keep everything else as on linux. This is my defensive approach.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1354862596

From mbaesken at openjdk.org  Wed Oct 11 12:23:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Oct 2023 12:23:10 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 12:06:54 GMT, Joachim Kern  wrote:

>> src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 43:
>> 
>>> 41: /*
>>> 42:  * Returns the children of the requested pid and optionally each parent and
>>> 43:  * start time. If requested pid is zero return all processes.
>> 
>> This deserves at least a better explanation, because I was first wondering why you return the parent pid since that would be just, well, the pid. Then I thought "oh, maybe he traverses indirect children too, then returning the respective parent pid would make sense". And then I saw that no, you only return direct children *unless* pid is 0. So the parent pid business makes only sense for the pid==0 case.
>> 
>> So, from looking at the implementation, the only point of the parent pid return array is if you pass in 0 as pid. This should be made clearer. Or even better, split this into two functions, one "get children(pid, returnpidarray)" and one "getAllProcesses(returnarray, ppid returnarray)".
>
> Hi Thomas, this function is just the same as the linux and macos implementation. And I do not want to make more changes as really needed, otherwise the siblings character gets lost. Following your proposal means to do the split for linux and macos too. And to be honest, I do not really know the intention of the function, maybe the implementation is wrong on all platforms. So my goal was to only exchange the used API and keep everything else as on linux. This is my defensive approach.

Probably keep the function without split into 2 functions, but just adjust the comment a bit  as Thomas suggested ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1354878044

From mbaesken at openjdk.org  Wed Oct 11 13:02:08 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Oct 2023 13:02:08 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 10:57:24 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes 2

`/* skip files that aren't numbers */`

The comment is probably outdated and from the time when we looked at /proc fs in the old version .
So maybe adjust the comment or remove it if it is obsolete now ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1757645051

From dl at openjdk.org  Wed Oct 11 13:07:08 2023
From: dl at openjdk.org (Doug Lea)
Date: Wed, 11 Oct 2023 13:07:08 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v49]
In-Reply-To: 
References: 
Message-ID: 

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  More cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/5f40a9d2..45585dc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=47-48

  Stats: 11 lines in 3 files changed: 1 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From rriggs at openjdk.org  Wed Oct 11 13:34:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Oct 2023 13:34:35 GMT
Subject: RFR: 8317956: Make jdk.internal.util.Architecture current architecture
 final
Message-ID: 

The static for the current architecture should be final to allow some optimizations.

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

Commit messages:
 - 8317956: Make jdk.internal.util.Archecture current architecture final

Changes: https://git.openjdk.org/jdk/pull/16150/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16150&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317956
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16150/head:pull/16150

PR: https://git.openjdk.org/jdk/pull/16150

From pminborg at openjdk.org  Wed Oct 11 13:34:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 13:34:35 GMT
Subject: RFR: 8317956: Make jdk.internal.util.Architecture current
 architecture final
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 Oct 2023 13:25:14 GMT, Roger Riggs  wrote:

> The static for the current architecture should be final to allow some optimizations.

Marked as reviewed by pminborg (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16150#pullrequestreview-1671239088

From redestad at openjdk.org  Wed Oct 11 13:43:06 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 11 Oct 2023 13:43:06 GMT
Subject: RFR: 8317956: Make jdk.internal.util.Architecture current
 architecture final
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 Oct 2023 13:25:14 GMT, Roger Riggs  wrote:

> The static for the current architecture should be final to allow some optimizations.

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16150#pullrequestreview-1671269560

From mdonovan at openjdk.org  Wed Oct 11 13:53:58 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 11 Oct 2023 13:53:58 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.

Matthew Donovan has updated the pull request with a new target base 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 socket-params
 - Merge branch 'master' into socket-params
 - added javadocs to new methods
 - 8303525: Refactor/cleanup open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14932/files
  - new: https://git.openjdk.org/jdk/pull/14932/files/9937812b..35c0a881

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14932&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14932&range=00-01

  Stats: 206699 lines in 5077 files changed: 100226 ins; 50943 del; 55530 mod
  Patch: https://git.openjdk.org/jdk/pull/14932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14932/head:pull/14932

PR: https://git.openjdk.org/jdk/pull/14932

From rriggs at openjdk.org  Wed Oct 11 13:55:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Oct 2023 13:55:59 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 12:20:00 GMT, Matthias Baesken  wrote:

>> Hi Thomas, this function is just the same as the linux and macos implementation. And I do not want to make more changes as really needed, otherwise the siblings character gets lost. Following your proposal means to do the split for linux and macos too. And to be honest, I do not really know the intention of the function, maybe the implementation is wrong on all platforms. So my goal was to only exchange the used API and keep everything else as on linux. This is my defensive approach.
>
> Probably keep the function without split into 2 functions, but just adjust the comment a bit  as Thomas suggested ?

The callers in ProcessHandlerImpl depend on knowing the parent pid for each process. 
They are used to find the descendants of a process. When reading /proc that's necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1355048484

From rriggs at openjdk.org  Wed Oct 11 14:01:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Oct 2023 14:01:02 GMT
Subject: RFR: 8317874: Add @sealedGraph to StringTemplate.Processor.Linkage
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 Oct 2023 08:07:31 GMT, Per Minborg  wrote:

> This PR proposes to Add @sealedGraph to `StringTemplate.Processor.Linkage`

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16141#pullrequestreview-1671316636

From jkern at openjdk.org  Wed Oct 11 14:10:24 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 11 Oct 2023 14:10:24 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 13:52:54 GMT, Roger Riggs  wrote:

>> Probably keep the function without split into 2 functions, but just adjust the comment a bit  as Thomas suggested ?
>
> The callers in ProcessHandlerImpl depend on knowing the parent pid for each process. 
> They are used to find the descendants of a process. When reading /proc that's necessary.

@RogerRiggs Roger you are most familiar with os_getChildren(). How would you phrase the introducing comment of this function?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1355069604

From abimpoudis at openjdk.org  Wed Oct 11 14:48:48 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 11 Oct 2023 14:48:48 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v4]
In-Reply-To: 
References: 
Message-ID: <2zeqTfDRUNUZHuCJXwaumAoE-SlE2neEv0AKfDz2XYU=.7da6a633-c7c8-4a1f-9d43-0b1b5ab0fb32@github.com>

> This PR finalizes the feature of unnamed variables and patterns.

Aggelos Biboudis has updated the pull request with a new target base 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:

 - Add test with multi-catch
 - Merge branch 'master' into unnamed
 - Address review by @mcimadamore
 - Address review by @lahodaj
 - 8315532: Compiler Implementation for Unnamed Variables and Patterns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/630b128e..ccbfbd4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=02-03

  Stats: 99666 lines in 2717 files changed: 41569 ins; 19343 del; 38754 mod
  Patch: https://git.openjdk.org/jdk/pull/15649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649

PR: https://git.openjdk.org/jdk/pull/15649

From alanb at openjdk.org  Wed Oct 11 15:03:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Oct 2023 15:03:27 GMT
Subject: RFR: 8317870: Add @sealedGraph to Thread.Builder
In-Reply-To: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>
References: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>
Message-ID: <2SvM6WuryGqupwuufSaGMKMEOadhn8kCDQSe9wIiX_w=.4d7d5432-0357-47bc-9432-396a6e544758@github.com>

On Wed, 11 Oct 2023 07:52:54 GMT, Per Minborg  wrote:

> This PR proposes to Add @sealedGraph to `Thread.Builder`.

@pron Do you have any comment on this one? I remember we decided not to do this in JDK 21.

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

PR Comment: https://git.openjdk.org/jdk/pull/16138#issuecomment-1757891820

From rpressler at openjdk.org  Wed Oct 11 15:08:33 2023
From: rpressler at openjdk.org (Ron Pressler)
Date: Wed, 11 Oct 2023 15:08:33 GMT
Subject: RFR: 8317870: Add @sealedGraph to Thread.Builder
In-Reply-To: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>
References: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>
Message-ID: 

On Wed, 11 Oct 2023 07:52:54 GMT, Per Minborg  wrote:

> This PR proposes to Add @sealedGraph to `Thread.Builder`.

I don't think it's helpful here.

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

PR Comment: https://git.openjdk.org/jdk/pull/16138#issuecomment-1757905176

From bpb at openjdk.org  Wed Oct 11 15:20:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Oct 2023 15:20:02 GMT
Subject: RFR: 8317956: Make jdk.internal.util.Architecture current
 architecture final
In-Reply-To: 
References: 
Message-ID: <0JbEanWPwbBcBQRa-Ri7azx2-Zy_KlZ2UX33VTydTwA=.de6d423a-8f67-424d-bc07-4e226cd06cc5@github.com>

On Wed, 11 Oct 2023 13:25:14 GMT, Roger Riggs  wrote:

> The static for the current architecture should be final to allow some optimizations.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16150#pullrequestreview-1671532716

From bpb at openjdk.org  Wed Oct 11 15:26:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Oct 2023 15:26:08 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory
In-Reply-To: 
References: 
 
Message-ID: <756cbIMGgojlowzB2bqHIRghHreCiKcNFkSsH4L905k=.bcdb9ada-4f8b-4fab-a9ae-6dfc1057f46b@github.com>

On Wed, 11 Oct 2023 10:25:39 GMT, Raffaello Giulietti  wrote:

>> Change test to use `RandomFactory` instead of `new Random()` and convert it to JUnit 5.
>
> test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal.java line 115:
> 
>> 113:         }
>> 114: 
>> 115:         assertTrue(failures == 0);
> 
> Suggestion:
> 
>         assertEquals(0, failures);
> 
> Gives a better message because it explicitly knows both the expected value (1st arg) and the actual value (2nd arg).
> Similarly for other `assertTrue` usages below).

Good suggestion! Thanks. I'll change it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16130#discussion_r1355213567

From abimpoudis at openjdk.org  Wed Oct 11 15:43:19 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 11 Oct 2023 15:43:19 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/3c0d85e9..d06b2172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=17-18

  Stats: 18 lines in 2 files changed: 10 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From bpb at openjdk.org  Wed Oct 11 15:45:29 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Oct 2023 15:45:29 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory [v2]
In-Reply-To: 
References: 
Message-ID: 

> Change test to use `RandomFactory` instead of `new Random()` and convert it to JUnit 5.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8313621: assertTrue -> assertEquals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16130/files
  - new: https://git.openjdk.org/jdk/pull/16130/files/639a2db3..3f4fc63d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16130&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16130&range=00-01

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16130/head:pull/16130

PR: https://git.openjdk.org/jdk/pull/16130

From bpb at openjdk.org  Wed Oct 11 15:45:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Oct 2023 15:45:30 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory [v2]
In-Reply-To: <756cbIMGgojlowzB2bqHIRghHreCiKcNFkSsH4L905k=.bcdb9ada-4f8b-4fab-a9ae-6dfc1057f46b@github.com>
References: 
 
 <756cbIMGgojlowzB2bqHIRghHreCiKcNFkSsH4L905k=.bcdb9ada-4f8b-4fab-a9ae-6dfc1057f46b@github.com>
Message-ID: 

On Wed, 11 Oct 2023 15:22:59 GMT, Brian Burkhalter  wrote:

>> test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal.java line 115:
>> 
>>> 113:         }
>>> 114: 
>>> 115:         assertTrue(failures == 0);
>> 
>> Suggestion:
>> 
>>         assertEquals(0, failures);
>> 
>> Gives a better message because it explicitly knows both the expected value (1st arg) and the actual value (2nd arg).
>> Similarly for other `assertTrue` usages below).
>
> Good suggestion! Thanks. I'll change it.

So changed in 3f4fc63d3f1657caef467e2fa09d846d750dcad4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16130#discussion_r1355250130

From markus at headcrashing.eu  Sun Oct  8 13:14:15 2023
From: markus at headcrashing.eu (Markus Karg)
Date: Sun, 8 Oct 2023 15:14:15 +0200
Subject: AW: RFC: 8309726: Reader::readString
In-Reply-To: 
References: <000001d99b8f$b6e1a4d0$24a4ee70$@eu>
 
Message-ID: <002801d9f9e9$5664e7d0$032eb770$@eu>

Aleksei,

 

thank you for reposting to the "right" mailing list, and everybody thank you for contribution to this discussion, but please note that it was *not me* who posted to the "wrong" list: In fact, I just opened this issue https://bugs.openjdk.org/browse/JDK-8309726, and it was *the OpenJDK infrastructure* which in turn posted to the "wrong" list. I am not aware who is in charge to fix this, but *I* cannot change this behvior. Maybe the one in charge is reading this and can fix it?

 

Thanks                                                                                             

-Markus

 

 

Von: Aleksei Ivanov [mailto:alexey.ivanov at oracle.com] 
Gesendet: Donnerstag, 5. Oktober 2023 14:16
An: Markus Karg; core-libs
Cc: client-libs-dev at openjdk.org
Betreff: Re: RFC: 8309726: Reader::readString

 

Hi Markus,

You posted it to the wrong list, it belongs on core-libs-dev.

-- 
Regards,
Alexey

On 10/06/2023 12:35, Markus Karg wrote:

By analyzing several existing applications I noticed that many of them need to read a String from an input source (be it an input stream or a reader), and there are a lot of solutions applied which all are more or less suboptimal:

* Files.readString(Path) - Fast, convenient, uses JLA.newStringNoRepl, only works with files (not with sockets or other sources).
* new String(inputStream.readAllBytes()) - Fast, complex, enforces dealing with an array in user code, cannot use JLA.newStringNoRepl.
* bufferedReader.lines().collect(StringBuilder::new, StringBuilder::append, StringBuilder::append).toString(); - Complex, enforces dealing with a stream in user code, doesn't use JLA.newStringNoRepl.
* reader.transferTo(stringWriter); stringWriter.toString(); - Medium convient, medium performance, synchronized as it relies on StringBuffer instead of StringBuilder.
* Custom loop using char[] of various default sizes (some 8k, some 16k, some configurable) - Slow, complex, doesn't use JLA.newStringNoRepl.
* etc.

Checking back with the particular authors of these applications I noticed that what they all miss is (a) guidance which solution is "best" (mostly thinking in speed, but also in reduced GC stress and memory consumption), (b) something convenient like Files.readString() but working with any reader implementation, not just with files.

I think we can do better, hence I'd like to propose the introduction of a new Reader::readString method. The benefits are:
* Guidance. The introduction of this method is a clear signal to all application programmers to use *this* one by default.
* Convenience. It couldn't be any easier for the caller.
* Performance. OpenJDK committers can optimize it for both, convenience, speed, reduced GC stress, and memory consumption, at the very same time.
* Optimizable. Each Reader implementation can choose an algorithm fitting best its own needs, while java.io.Reader itself provides a convenient default implementation based on a loop over this.read().

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rriggs at openjdk.org  Wed Oct 11 16:40:21 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 11 Oct 2023 16:40:21 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: <_OLTDOEtDefW6QyqFeYKd2Hh31Hx4q-FzYDex5wD3GA=.11f46a7e-1a0d-4619-b0e9-4757221ce4e5@github.com>

On Wed, 11 Oct 2023 14:07:00 GMT, Joachim Kern  wrote:

>> The callers in ProcessHandlerImpl depend on knowing the parent pid for each process. 
>> They are used to find the descendants of a process. When reading /proc that's necessary.
>
> @RogerRiggs Roger you are most familiar with os_getChildren(). How would you phrase the introducing comment of this function?

How about this in both the _unix.c and _aix.c files:

 * Return pids of active processes, and optionally parent pids and start times
 * for each process. 
 * For a specific non-zero pid, only the direct children are returned.
 * If the pid is zero, all active processes are returned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1355343311

From pminborg at openjdk.org  Wed Oct 11 16:40:57 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 16:40:57 GMT
Subject: Integrated: 8317874: Add @sealedGraph to
 StringTemplate.Processor.Linkage
In-Reply-To: 
References: 
Message-ID: <47nv4JjkT3gJXlMhvUZ4OAxcf1MUZnvbxQcJz8lVOsc=.54315dd9-fd13-4d94-81bf-83a8725ad848@github.com>

On Wed, 11 Oct 2023 08:07:31 GMT, Per Minborg  wrote:

> This PR proposes to Add @sealedGraph to `StringTemplate.Processor.Linkage`

This pull request has now been integrated.

Changeset: 2d46b297
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/2d46b29728b4dd371c6607245e5ed5e18147de30
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8317874: Add @sealedGraph to StringTemplate.Processor.Linkage

Reviewed-by: rriggs

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

PR: https://git.openjdk.org/jdk/pull/16141

From smarks at openjdk.org  Wed Oct 11 16:45:37 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 11 Oct 2023 16:45:37 GMT
Subject: Integrated: 8314896: additional clarifications to reversed() default
 methods' implementation requirements
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 21:12:44 GMT, Stuart Marks  wrote:

> Wording changes to make clear that the scenarios described are merely examples and are not normative requirements.

This pull request has now been integrated.

Changeset: 3f6d0168
Author:    Stuart Marks 
URL:       https://git.openjdk.org/jdk/commit/3f6d01687c06211f49ce6b238d8a7aa6876262cd
Stats:     12 lines in 4 files changed: 0 ins; 0 del; 12 mod

8314896: additional clarifications to reversed() default methods' implementation requirements

Reviewed-by: bchristi

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

PR: https://git.openjdk.org/jdk/pull/15799

From smarks at openjdk.org  Wed Oct 11 16:48:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 11 Oct 2023 16:48:07 GMT
Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 8 Sep 2023 16:13:16 GMT, Per Minborg  wrote:

>> This PR proposes to slightly improve some iterators of `AbstractMap`:
>> 
>> * Declare two fields `final`
>> * Use distinct classes rather than anonymous classes
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix additional formating issue
>  - Don't use polymorphism and reformat code

Marked as reviewed by smarks (Reviewer).

src/java.base/share/classes/java/util/AbstractMap.java line 901:

> 899: 
> 900:     // Iterator implementations.
> 901:     // Here, we avoid polymorphism to ensure full VM optimization capabilities.

I would remove this comment about avoiding polymorphism, since I think it's a total red herring and is potentially confusing. Otherwise this is fine.

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

PR Review: https://git.openjdk.org/jdk/pull/15615#pullrequestreview-1671892215
PR Review Comment: https://git.openjdk.org/jdk/pull/15615#discussion_r1355366295

From alexey.ivanov at oracle.com  Wed Oct 11 17:13:40 2023
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Wed, 11 Oct 2023 18:13:40 +0100
Subject: RFC: 8309726: Reader::readString
In-Reply-To: <002801d9f9e9$5664e7d0$032eb770$@eu>
References: <000001d99b8f$b6e1a4d0$24a4ee70$@eu>
 
 <002801d9f9e9$5664e7d0$032eb770$@eu>
Message-ID: 

Hi Markus,

I see. I didn't know there was a feature which automatically sends 
emails about submitted enhancements. It's the first time I see such an 
email.

You changed the component from client-libs to core-libs in JDK-8309726, 
which is correct, but the email had already been sent.

-- 
Regards,
Alexey

On 08/10/2023 14:14, Markus Karg wrote:
>
> Aleksei,
>
> thank you for reposting to the "right" mailing list, and everybody 
> thank you for contribution to this discussion, but please note that it 
> was *not me* who posted to the "wrong" list: In fact, I just opened 
> this issue https://bugs.openjdk.org/browse/JDK-8309726, and it was 
> *the OpenJDK infrastructure* which in turn posted to the "wrong" list. 
> I am not aware who is in charge to fix this, but *I* cannot change 
> this behvior. Maybe the one in charge is reading this and can fix it?
>
> Thanks
>
> -Markus
>
> *Von:*Aleksei Ivanov [mailto:alexey.ivanov at oracle.com]
> *Gesendet:* Donnerstag, 5. Oktober 2023 14:16
> *An:* Markus Karg; core-libs
> *Cc:* client-libs-dev at openjdk.org
> *Betreff:* Re: RFC: 8309726: Reader::readString
>
> Hi Markus,
>
> You posted it to the wrong list, it belongs on core-libs-dev.
>
> -- 
> Regards,
> Alexey
>
> On 10/06/2023 12:35, Markus Karg wrote:
>
>     By analyzing several existing applications I noticed that many of
>     them need to read a String from an input source (be it an input
>     stream or a reader), and there are a lot of solutions applied
>     which all are more or less suboptimal:
>
>     * Files.readString(Path) - Fast, convenient, uses
>     JLA.newStringNoRepl, only works with files (not with sockets or
>     other sources).
>     * new String(inputStream.readAllBytes()) - Fast, complex, enforces
>     dealing with an array in user code, cannot use JLA.newStringNoRepl.
>     * bufferedReader.lines().collect(StringBuilder::new,
>     StringBuilder::append, StringBuilder::append).toString(); -
>     Complex, enforces dealing with a stream in user code, doesn't use
>     JLA.newStringNoRepl.
>     * reader.transferTo(stringWriter); stringWriter.toString(); -
>     Medium convient, medium performance, synchronized as it relies on
>     StringBuffer instead of StringBuilder.
>     * Custom loop using char[] of various default sizes (some 8k, some
>     16k, some configurable) - Slow, complex, doesn't use
>     JLA.newStringNoRepl.
>     * etc.
>
>     Checking back with the particular authors of these applications I
>     noticed that what they all miss is (a) guidance which solution is
>     "best" (mostly thinking in speed, but also in reduced GC stress
>     and memory consumption), (b) something convenient like
>     Files.readString() but working with any reader implementation, not
>     just with files.
>
>     I think we can do better, hence I'd like to propose the
>     introduction of a new Reader::readString method. The benefits are:
>     * Guidance. The introduction of this method is a clear signal to
>     all application programmers to use *this* one by default.
>     * Convenience. It couldn't be any easier for the caller.
>     * Performance. OpenJDK committers can optimize it for both,
>     convenience, speed, reduced GC stress, and memory consumption, at
>     the very same time.
>     * Optimizable. Each Reader implementation can choose an algorithm
>     fitting best its own needs, while java.io.Reader itself provides a
>     convenient default implementation based on a loop over this.read().
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Wed Oct 11 17:28:12 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Oct 2023 17:28:12 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
> The proposed changes are:
> 
> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
> 3) Minor changes in Javadoc strings

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Add @ForceInline annotation to insertion and mixedInsertion sort

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16124/files
  - new: https://git.openjdk.org/jdk/pull/16124/files/a565f1d8..1de07fb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16124&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16124&range=02-03

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16124/head:pull/16124

PR: https://git.openjdk.org/jdk/pull/16124

From duke at openjdk.org  Wed Oct 11 17:28:59 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Oct 2023 17:28:59 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: 
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
 
 
Message-ID: 

On Wed, 11 Oct 2023 06:59:47 GMT, iaroslavski  wrote:

> Also @forceinline in these changes only works for case when new intrinsics are not used. I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics. That will tell us which @forceinline annotations are needed.

Added `@ForceInline` annotations to `insertionSort` and `mixedInsertionSort` as it is helping arrays of small sizes when intrinsics are disabled.

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758151762

From sviswanathan at openjdk.org  Wed Oct 11 17:28:57 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 11 Oct 2023 17:28:57 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
 
Message-ID: <-alPhgwHs5gHvQ2yReZU2ILKmeRv8lsbofJFyOxL7Zk=.57397c5e-b1f8-44c4-bfb1-51a431fb955f@github.com>

On Wed, 11 Oct 2023 17:28:12 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ForceInline annotation to insertion and mixedInsertion sort

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16124#pullrequestreview-1672015105

From bpb at openjdk.org  Wed Oct 11 18:25:25 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Oct 2023 18:25:25 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 15:45:29 GMT, Brian Burkhalter  wrote:

>> Change test to use `RandomFactory` instead of `new Random()` and convert it to JUnit 5.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313621: assertTrue -> assertEquals

I should note that it is intentional to retain the looping inside the vlarious `@Test` methods. The test runs through 2_400_000 values generated by `Random` so I would expect that supplying the values by a `@MethodSource` or some such would generate a mammoth amount of output.

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

PR Comment: https://git.openjdk.org/jdk/pull/16130#issuecomment-1758255079

From sviswanathan at openjdk.org  Wed Oct 11 18:35:07 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 11 Oct 2023 18:35:07 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: 
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
 
Message-ID: 

On Tue, 10 Oct 2023 22:29:55 GMT, Vladimir Kozlov  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix whitespace in build script
>
> Also @forceinline in these changes only works for case when new intrinsics are not used.
> I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics.
> That will tell us which @forceinline annotations are needed.

@vnkozlov Please advice if we can integrate this PR or if you would like to run some tests first.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758270977

From sviswanathan at openjdk.org  Wed Oct 11 18:35:04 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 11 Oct 2023 18:35:04 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
In-Reply-To: <-IoxCx93JQjLWexw1E3PvX---kjb9yDiojjVVML5Has=.ae198edf-9a1c-4ee3-ba51-166887d0ae96@github.com>
References: 
 
 <-IoxCx93JQjLWexw1E3PvX---kjb9yDiojjVVML5Has=.ae198edf-9a1c-4ee3-ba51-166887d0ae96@github.com>
Message-ID: 

On Wed, 11 Oct 2023 09:25:15 GMT, Andrew Haley  wrote:

> > Forgive me, I might be missing something very obvious, but is there any particular reason to entirely disable the SIMD accelerated sort on Zen 4 rather than having an alternate code path for Zen 4 where it has the `compressstoreu` instructions split up into separate `compress` and `storeu` instructions so that Zen 4 platforms can still benefit from a decent degree of performance uplift from AVX512 acceleration of sort?
> 
> I don't think you're missing anything. This should be done, rather than disabling the intrinsic.

With this PR we want to fix the urgent Alpine Linux build issues and the Zen 4 perf regression. At the minimum, we don't want to hurt performance for Zen 4, hence restricting the intrinsic to only Intel for now as suggested in the [Reddit discussion](https://www.reddit.com/r/java/comments/171t5sj/comment/k3v9ko5/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button).  Improving perf for it could be a separate PR from someone more familiar with Zen 4.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758268675

From kvn at openjdk.org  Wed Oct 11 18:52:22 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 11 Oct 2023 18:52:22 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 10 Oct 2023 18:40:30 GMT, R1chterScale  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Forgive me, I might be missing something very obvious, but is there any particular reason to entirely disable the SIMD accelerated sort on Zen 4 rather than having an alternate code path for Zen 4 where it has the `compressstoreu` instructions split up into separate `compress` and `storeu` instructions so that Zen 4 platforms can still benefit from a decent degree of performance uplift from AVX512 acceleration of sort?

@R1chterScale or someone can suggest patch for Zen 4 and test it so we can include it into these changes?
Otherwise we will file separate followup RFE as Sandhya suggested?

And yes, I need to run testing before approval but after we decide what to do with Zen 4 in these changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758306441

From duke at openjdk.org  Wed Oct 11 18:54:50 2023
From: duke at openjdk.org (R1chterScale)
Date: Wed, 11 Oct 2023 18:54:50 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 17:28:12 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ForceInline annotation to insertion and mixedInsertion sort

Sorry, it's probably out of my capabilities to make something of acceptable quality. All I know is that it would be useful to reference the unmerged Zen 4 patch for the base implementation of x86-simd-sort

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758311612

From kvn at openjdk.org  Wed Oct 11 19:09:13 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 11 Oct 2023 19:09:13 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: 
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
 
 
Message-ID: 

On Wed, 11 Oct 2023 18:31:44 GMT, Sandhya Viswanathan  wrote:

>> Also @forceinline in these changes only works for case when new intrinsics are not used.
>> I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics.
>> That will tell us which @forceinline annotations are needed.
>
> @vnkozlov Please advice if we can integrate this PR or if you would like to run some tests first.

Okay. I will start testing for current changes. @sviswa7 please file RFE for Zen 4. If we get patch for it we do followup changes in that RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758342800

From duke at openjdk.org  Wed Oct 11 19:27:35 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 11 Oct 2023 19:27:35 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: 
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 17:22:56 GMT, Srinivas Vamsi Parasa  wrote:

> > Also @forceinline in these changes only works for case when new intrinsics are not used. I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics. That will tell us which @forceinline annotations are needed.
> 
> Added `@ForceInline` annotations to `insertionSort` and `mixedInsertionSort` as it is helping arrays of small sizes when intrinsics are disabled.
> 
> Thanks, Vamsi

@vamsi-parasa 
Please revert changes (adding @ForceInline to insertionSort and mixedInsertionSort) - I checked: initinal version works faster.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758387580

From joehw at openjdk.org  Wed Oct 11 19:31:05 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 11 Oct 2023 19:31:05 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 9 Oct 2023 14:42:33 GMT, Mahendra Chhipa  wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request with a new target base 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:
> 
>  - Implemented the review comments.
>    1. Now test uses Junit5.
>    2. Created the seperate Utility class to generate the JDK version specific java src file.
>  - Merge branch 'master' into JDK-8077371
>  - Implemented review comments.
>  - Implemented the review comments.
>  - Move the pseudo code generation part from setup() to seperate methods.
>  - 1. Added JDK version in Data files.
>    2. Updated copyright year.
>  - Implemented the review comments.
>  - Implemented the review comment.
>  - closed file handlers.
>  - JDK-8077371: Binary files in JAXP test should be removed

Thanks for the update. 

I'm not sure it's necessary to repeat tests with Base64 input. I think Daniel's comment was that the data can be optionally base64-encoded into a string, not that the tests needed to be duplicated. 

The generatePseudoCodeFor... methods in the Util class can be consolidated too.

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

PR Comment: https://git.openjdk.org/jdk/pull/13537#issuecomment-1758394086

From naoto at openjdk.org  Wed Oct 11 19:32:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Oct 2023 19:32:50 GMT
Subject: RFR: 8317873: Add @sealedGraph to IllegalFormatException
In-Reply-To: 
References: 
Message-ID: <68wk-gtagjUmdzVec2P3mUzXTQJ3MMcSg3U0OLkcLbo=.069cc3d9-a2db-4c62-908e-9490b36cccaa@github.com>

On Wed, 11 Oct 2023 07:59:24 GMT, Per Minborg  wrote:

> This PR proposes to add @sealedGraph to `IllegalFormatException`

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16140#pullrequestreview-1672385095

From kvn at openjdk.org  Wed Oct 11 19:38:28 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 11 Oct 2023 19:38:28 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: 
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 19:06:24 GMT, Vladimir Kozlov  wrote:

>> @vnkozlov Please advice if we can integrate this PR or if you would like to run some tests first.
>
> Okay. I will start testing for current changes. @sviswa7 please file RFE for Zen 4. If we get patch for it we do followup changes in that RFE.

> @vnkozlov
> Are there any options to be sure that C2 JIT compiler is used during tests?

May be you already figure out that. Use `-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -XX:-TieredCompilation` flags (Tiered is off to use only C2) and look for something like next

     82   20             java.util.Random::next (47 bytes)
                            @ 3   java.util.Random::next (47 bytes)   inline (hot)
                              @ 8   java.util.concurrent.atomic.AtomicLong::get (5 bytes)   accessor
                              @ 32   java.util.concurrent.atomic.AtomicLong::compareAndSet (13 bytes)   inline (hot)
                                @ 9   jdk.internal.misc.Unsafe::compareAndSetLong (0 bytes)   (intrinsic)

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758406966

From iris at openjdk.org  Wed Oct 11 19:46:18 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 11 Oct 2023 19:46:18 GMT
Subject: RFR: 8317873: Add @sealedGraph to IllegalFormatException
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 Oct 2023 07:59:24 GMT, Per Minborg  wrote:

> This PR proposes to add @sealedGraph to `IllegalFormatException`

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16140#pullrequestreview-1672411158

From duke at openjdk.org  Wed Oct 11 19:59:16 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Oct 2023 19:59:16 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 17:28:12 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ForceInline annotation to insertion and mixedInsertion sort

> > > Also @forceinline in these changes only works for case when new intrinsics are not used. I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics. That will tell us which @forceinline annotations are needed.
> > 
> > 
> > Added `@ForceInline` annotations to `insertionSort` and `mixedInsertionSort` as it is helping arrays of small sizes when intrinsics are disabled.
> > Thanks, Vamsi
> 
> @vamsi-parasa Please revert changes (adding @forceinline to insertionSort and mixedInsertionSort) - I checked: initinal version works faster.

@iaroslavski 
Vladimir, have you used `-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySort,_arrayPartition` to disable the intrinsics?
Also, it helps to have one warmup iteration of 30 secs to reduce run-to-run variance.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758437209

From duke at openjdk.org  Wed Oct 11 20:13:17 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 11 Oct 2023 20:13:17 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <7A48qFC8LUM_91XbZFt9WOorvpjiG5jBO79AT3bZCjg=.62e6ccfa-d150-4260-a976-329be9dcfc47@github.com>

On Wed, 11 Oct 2023 19:56:47 GMT, Srinivas Vamsi Parasa  wrote:

> > > > Also @forceinline in these changes only works for case when new intrinsics are not used. I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics. That will tell us which @forceinline annotations are needed.
> > > 
> > > 
> > > Added `@ForceInline` annotations to `insertionSort` and `mixedInsertionSort` as it is helping arrays of small sizes when intrinsics are disabled.
> > > Thanks, Vamsi
> > 
> > 
> > @vamsi-parasa Please revert changes (adding @forceinline to insertionSort and mixedInsertionSort) - I checked: initinal version works faster.
> 
> @iaroslavski Vladimir, have you used `-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySort,_arrayPartition` to disable the intrinsics? Also, it helps to have one warmup iteration of 30 secs to reduce run-to-run variance.

@vamsi-parasa 
Yes, I tried with the disabled mentioned intrinsics.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758458948

From duke at openjdk.org  Wed Oct 11 20:35:16 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Oct 2023 20:35:16 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: 
References: 
 <7uQXiY0QakPb2mrMiU3fXXOEcqamb34Q6atD0ZJ8ReE=.4dad0f4b-8e7c-430d-b6cf-370db71927ae@github.com>
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 07:10:57 GMT, iaroslavski  wrote:

> To have clear picture could you please run benchmarking to compare both cases: current implementation and implementation with Java insertionSort only?
> 
> see changes `sort(int.class, a, Unsafe.ARRAY_INT_BASE_OFFSET, low, high, DualPivotQuicksort::insertionSort);` -> `insertionSort(a, low, high);`

@iaroslavski 
Yes, the intrinsic is needed. 
I remember, the same question was asked in the original PR and data was provided in the original PR.
Even for a small say size=30, the AVX512 sort intrinsic is faster.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758489003

From duke at openjdk.org  Wed Oct 11 20:51:19 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 11 Oct 2023 20:51:19 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: <7A48qFC8LUM_91XbZFt9WOorvpjiG5jBO79AT3bZCjg=.62e6ccfa-d150-4260-a976-329be9dcfc47@github.com>
References: 
 
 
 <7A48qFC8LUM_91XbZFt9WOorvpjiG5jBO79AT3bZCjg=.62e6ccfa-d150-4260-a976-329be9dcfc47@github.com>
Message-ID: 

On Wed, 11 Oct 2023 20:10:12 GMT, iaroslavski  wrote:

> > > > > Also @forceinline in these changes only works for case when new intrinsics are not used. I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics. That will tell us which @forceinline annotations are needed.
> > > > 
> > > > 
> > > > Added `@ForceInline` annotations to `insertionSort` and `mixedInsertionSort` as it is helping arrays of small sizes when intrinsics are disabled.
> > > > Thanks, Vamsi
> > > 
> > > @vamsi-parasa Please revert changes (adding @forceinline to insertionSort and mixedInsertionSort) - I checked: initinal version works faster.
> > 
> > @iaroslavski Vladimir, have you used `-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySort,_arrayPartition` to disable the intrinsics? Also, it helps to have one warmup iteration of 30 secs to reduce run-to-run variance.
> 
> @vamsi-parasa Yes, I tried with the disabled mentioned intrinsics.

@vamsi-parasa, and no profit with @forceinline on insertionSort and mixedInsertionSort.
I suggest removing @forceinline from insertionSort and mixedInsertionSort.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758516159

From erikj at openjdk.org  Wed Oct 11 20:51:23 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 11 Oct 2023 20:51:23 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 17:28:12 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ForceInline annotation to insertion and mixedInsertion sort

make/modules/java.base/Lib.gmk line 230:

> 228:       CFLAGS := $(CFLAGS_JDKLIB) $(LIBFFI_CFLAGS), \
> 229:       LDFLAGS := $(LDFLAGS_JDKLIB) \
> 230:                  $(call SET_SHARED_LIBRARY_ORIGIN), \

If you are going to fix the indentation here, please do it to follow the code conventions for the build system:
https://openjdk.org/groups/build/doc/code-conventions.html

2. If a line must be broken, use four spaces for indentation.
18. Avoid padding internally in a line with spaces to try to align some feature into columns with surrounding lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16124#discussion_r1355763767

From duke at openjdk.org  Wed Oct 11 20:58:23 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Oct 2023 20:58:23 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
> The proposed changes are:
> 
> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
> 3) Minor changes in Javadoc strings

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Revert @ForceInline annotations for small array sort methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16124/files
  - new: https://git.openjdk.org/jdk/pull/16124/files/1de07fb7..9bce6804

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16124&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16124&range=03-04

  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16124/head:pull/16124

PR: https://git.openjdk.org/jdk/pull/16124

From duke at openjdk.org  Wed Oct 11 20:58:25 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Oct 2023 20:58:25 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v2]
In-Reply-To: 
References: 
 <7uQXiY0QakPb2mrMiU3fXXOEcqamb34Q6atD0ZJ8ReE=.4dad0f4b-8e7c-430d-b6cf-370db71927ae@github.com>
 
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 20:31:05 GMT, Srinivas Vamsi Parasa  wrote:

>> Hi @vamsi-parasa,
>> 
>> Both methods mixedInsertionSort and insertionSort are covered by intrinsics.
>> But insertionSort is run on leftmnost (one) part only and on small ( < MAX_INSERTION_SORT_SIZE = 44) arrays.
>> Do we actually need to use intrinsics for it?
>> 
>> To have clear picture could you please run benchmarking to compare both cases:
>> current implementation and implementation with Java insertionSort only?
>> 
>> see changes `sort(int.class, a, Unsafe.ARRAY_INT_BASE_OFFSET, low, high, DualPivotQuicksort::insertionSort);`
>> ->
>> `insertionSort(a, low, high);`
>
>> To have clear picture could you please run benchmarking to compare both cases: current implementation and implementation with Java insertionSort only?
>> 
>> see changes `sort(int.class, a, Unsafe.ARRAY_INT_BASE_OFFSET, low, high, DualPivotQuicksort::insertionSort);` -> `insertionSort(a, low, high);`
> 
> @iaroslavski 
> Yes, the intrinsic is needed. 
> I remember, the same question was asked in the original PR and data was provided in the original PR.
> Even for a small say size=30, the AVX512 sort intrinsic is faster.

> @vamsi-parasa, and no profit with @forceinline on insertionSort and mixedInsertionSort. I suggest removing @forceinline from insertionSort and mixedInsertionSort.

@iaroslavski,  Please see the change reverted.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758522236

From duke at openjdk.org  Wed Oct 11 21:07:20 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 11 Oct 2023 21:07:20 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 11 Oct 2023 20:48:06 GMT, Erik Joelsson  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @ForceInline annotation to insertion and mixedInsertion sort
>
> make/modules/java.base/Lib.gmk line 230:
> 
>> 228:       CFLAGS := $(CFLAGS_JDKLIB) $(LIBFFI_CFLAGS), \
>> 229:       LDFLAGS := $(LDFLAGS_JDKLIB) \
>> 230:                  $(call SET_SHARED_LIBRARY_ORIGIN), \
> 
> If you are going to fix the indentation here, please do it to follow the code conventions for the build system:
> https://openjdk.org/groups/build/doc/code-conventions.html
> 
> 2. If a line must be broken, use four spaces for indentation.
> 18. Avoid padding internally in a line with spaces to try to align some feature into columns with surrounding lines.

Hi Erik (@erikj79), 
BUILD_LIBFALLBACKLINKER is from different PR (#13079). If I understand correctly, for LIB_SIMD_SORT, are you suggesting that we don't pad the lines with spaces to align features into columns and instead just use 4 spaces for the indentation after the line break?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16124#discussion_r1355779727

From sviswanathan at openjdk.org  Wed Oct 11 21:15:16 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 11 Oct 2023 21:15:16 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v3]
In-Reply-To: 
References: 
 <_93Mupwp_FZby7MJQ5AnVvpmMdnYHjCUNG9M5H7npEg=.6ac0dad4-dfc6-4726-9aeb-e548b06de45a@github.com>
 
 
Message-ID: <_o2XIAQuEXMsf84coUsJzK1TQ3HwG-rtvHersZH5m6Y=.f90caa7b-8e2d-4cd1-bcb5-14f230797e7f@github.com>

On Wed, 11 Oct 2023 18:31:44 GMT, Sandhya Viswanathan  wrote:

>> Also @forceinline in these changes only works for case when new intrinsics are not used.
>> I would suggest to adapt/update JMH benchmark to cover all cases and see effect @forceinline without intrinsics.
>> That will tell us which @forceinline annotations are needed.
>
> @vnkozlov Please advice if we can integrate this PR or if you would like to run some tests first.

> Okay. I will start testing for current changes. @sviswa7 please file RFE for Zen 4. If we get patch for it we do followup changes in that RFE.

Thanks a lot Vladimir. RFE filed: https://bugs.openjdk.org/browse/JDK-8317976.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758550761

From jlu at openjdk.org  Wed Oct 11 21:20:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Oct 2023 21:20:47 GMT
Subject: RFR: JDK-8317372: Refactor some NumberFormat tests to use JUnit
 [v2]
In-Reply-To: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
Message-ID: 

> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
> 
> During the switch to JUnit, the tests had the following updates (to improve readability)
> - separate the test data generation from the actual execution of the test
> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Reflect review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16035/files
  - new: https://git.openjdk.org/jdk/pull/16035/files/415230bd..22d7e1a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16035&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16035&range=00-01

  Stats: 31 lines in 5 files changed: 6 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/16035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16035/head:pull/16035

PR: https://git.openjdk.org/jdk/pull/16035

From jlu at openjdk.org  Wed Oct 11 21:20:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Oct 2023 21:20:48 GMT
Subject: RFR: JDK-8317372: Refactor some NumberFormat tests to use JUnit
 [v2]
In-Reply-To: 
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
 
Message-ID: 

On Mon, 9 Oct 2023 20:13:39 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect review comments
>
> test/jdk/java/text/Format/NumberFormat/BigDecimalCompatibilityTest.java line 162:
> 
>> 160:         // Check parse and returned value
>> 161:         Number parsedValue = assertDoesNotThrow(()-> df.parse(longString),
>> 162:                 "Should not throw a ParseException");
> 
> It could catch any exception, so the message could be broader. Maybe just `a ParseException` -> `an Exception`.

Thank you for the review. I Adjusted the message, but clarified in the comment that the original intention was checking for a `ParseException`; fixed in the other instances as well.

> test/jdk/java/text/Format/NumberFormat/Bug4838107.java line 254:
> 
>> 252:                     "\n\tre-parsed number: " + parsed2 +
>> 253:                     "  (" + parsed2.getClass().getName() + ")" +
>> 254:                     "\n\tminus sign: " + df.getDecimalFormatSymbols().getMinusSign());
> 
> Could use text block to get rid of `\n`/`\t`s, with `.formatted()`. Same for the following one.

Adjusted.

> test/jdk/java/text/Format/NumberFormat/Bug8132125.java line 47:
> 
>> 45:         NumberFormat nf = NumberFormat.getInstance(deCH);
>> 46: 
>> 47:         // i.e. "\u2019" as decimal separator, "\u2019" as grouping separator
> 
> This is incorrect (sorry, I am to be blamed as I wrote this ?). Should be "`\u002E` as decimal separator, " also remove `i.e.` if you move the comment on top of the variable declaration

Fixed.

> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 62:
> 
>> 60:     // currencySymbolsTest() is only ran for COMPAT
>> 61:     private static final boolean isCompat =
>> 62:             "COMPAT".equals(System.getProperty("java.locale.providers"));
> 
> This check could be moved into `currencySymbolsTest()`

I left it as a static declaration as although it is used in `currencySymbolsTest()`, it is also used in the data provider of `CurrencyFormatTest()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355790743
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355790850
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355790950
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355791032

From duke at openjdk.org  Wed Oct 11 21:26:15 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 11 Oct 2023 21:26:15 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v3]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: 

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix from @cl4es 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/05406d99..72824dd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From duke at openjdk.org  Wed Oct 11 21:46:04 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 11 Oct 2023 21:46:04 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: 

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix from @cl4es 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/72824dd5..eec631cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From naoto at openjdk.org  Wed Oct 11 22:02:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Oct 2023 22:02:17 GMT
Subject: RFR: JDK-8317372: Refactor some NumberFormat tests to use JUnit
 [v2]
In-Reply-To: 
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
 
Message-ID: <8SVCe1xbvTs9SNwhKnNgS_Sli6VJXIfS31qCXkaHUeU=.c427f4da-9436-4338-8efa-f6a30ba09c24@github.com>

On Wed, 11 Oct 2023 21:20:47 GMT, Justin Lu  wrote:

>> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
>> 
>> During the switch to JUnit, the tests had the following updates (to improve readability)
>> - separate the test data generation from the actual execution of the test
>> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comments

test/jdk/java/text/Format/NumberFormat/Bug8132125.java line 47:

> 45:         NumberFormat nf = NumberFormat.getInstance(deCH);
> 46: 
> 47:         // "\u2019" as decimal separator, "\u002E" as grouping separator

"\u002E" is decimal, "\u2019" is grouping.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355824830

From naoto at openjdk.org  Wed Oct 11 22:02:19 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Oct 2023 22:02:19 GMT
Subject: RFR: JDK-8317372: Refactor some NumberFormat tests to use JUnit
 [v2]
In-Reply-To: 
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
 
 
Message-ID: 

On Wed, 11 Oct 2023 21:15:42 GMT, Justin Lu  wrote:

>> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 62:
>> 
>>> 60:     // currencySymbolsTest() is only ran for COMPAT
>>> 61:     private static final boolean isCompat =
>>> 62:             "COMPAT".equals(System.getProperty("java.locale.providers"));
>> 
>> This check could be moved into `currencySymbolsTest()`
>
> I left it as a static declaration as although it is used in `currencySymbolsTest()`, it is also used in the data provider of `CurrencyFormatTest()`.

Missed that. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355821515

From duke at openjdk.org  Wed Oct 11 22:13:19 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 11 Oct 2023 22:13:19 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v2]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
Message-ID: 

On Wed, 11 Oct 2023 09:48:58 GMT, Claes Redestad  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refactor based on @liach 's review
>
> src/java.base/share/classes/java/math/BigDecimal.java line 4168:
> 
>> 4166:             int lowInt = (int)intCompact % 100;
>> 4167:             int highInt = (int)intCompact / 100;
>> 4168:             int highIntSize = JLA.stringSize(highInt);
> 
> Which micros cover performance of this branch?
> 
> What performance would you get if you simplified this to, say, `return highInt + (lowInt < 10 ? ".0" : ".") + lowInt;`?
> 
> `lowInt` is currently unused since you use `(int) intCompact - highInt * 100` instead below. (While a clever optimization in theory, I believe the JIT should handle a pair of integer modulo and division operations (`a = intValue % 100; b = intValue / 100`) so that it only has to do one division, so please measure that whatever you do here has a significant benefit).

Performance numbers run on MacBook M1 Max:

-Benchmark                                 Mode  Cnt     Score    Error  Units
-BigDecimals.testHugeToEngineeringString   avgt   15   217.619 ?  4.617  ns/op
-BigDecimals.testLargeToEngineeringString  avgt   15    65.183 ?  4.368  ns/op
-BigDecimals.testSmallToEngineeringString  avgt   15    17.084 ?  0.056  ns/op
-BigDecimals.testToEngineeringString       avgt   15  1856.849 ? 63.571  ns/op

+Benchmark                                 Mode  Cnt     Score    Error  Units (eec631c)
+BigDecimals.testHugeToEngineeringString   avgt   15   164.910 ?  1.514  ns/op (+31.97)
+BigDecimals.testLargeToEngineeringString  avgt   15    20.826 ?  0.066  ns/op (+212.99)
+BigDecimals.testSmallToEngineeringString  avgt   15    11.987 ?  0.080  ns/op (+42.53)
+BigDecimals.testToEngineeringString       avgt   15  1854.372 ? 63.810  ns/op (+0.14)


The microben covered by fast-path is BigDecimals.testSmallToEngineeringString, highInt + (lowInt < 10 ? ".0" : ".") + lowInt is actually implemented based on StringBuilder and will be much slower than the current baseline.

Benchmark                                 Mode  Cnt   Score   Error  Units (use StringConcat)
BigDecimals.testSmallToEngineeringString  avgt   15  41.876 ? 0.182  ns/op

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1355833197

From kvn at openjdk.org  Wed Oct 11 22:15:17 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 11 Oct 2023 22:15:17 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 20:58:23 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert @ForceInline annotations for small array sort methods

I started testing for v04 assuming if you make make file changes they will be cosmetic.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758619820

From duke at openjdk.org  Wed Oct 11 22:16:14 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 11 Oct 2023 22:16:14 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v2]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 22:10:45 GMT, Shaojin Wen  wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 4168:
>> 
>>> 4166:             int lowInt = (int)intCompact % 100;
>>> 4167:             int highInt = (int)intCompact / 100;
>>> 4168:             int highIntSize = JLA.stringSize(highInt);
>> 
>> Which micros cover performance of this branch?
>> 
>> What performance would you get if you simplified this to, say, `return highInt + (lowInt < 10 ? ".0" : ".") + lowInt;`?
>> 
>> `lowInt` is currently unused since you use `(int) intCompact - highInt * 100` instead below. (While a clever optimization in theory, I believe the JIT should handle a pair of integer modulo and division operations (`a = intValue % 100; b = intValue / 100`) so that it only has to do one division, so please measure that whatever you do here has a significant benefit).
>
> Performance numbers run on MacBook M1 Max:
> 
> -Benchmark                                 Mode  Cnt     Score    Error  Units
> -BigDecimals.testHugeToEngineeringString   avgt   15   217.619 ?  4.617  ns/op
> -BigDecimals.testLargeToEngineeringString  avgt   15    65.183 ?  4.368  ns/op
> -BigDecimals.testSmallToEngineeringString  avgt   15    17.084 ?  0.056  ns/op
> -BigDecimals.testToEngineeringString       avgt   15  1856.849 ? 63.571  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (eec631c)
> +BigDecimals.testHugeToEngineeringString   avgt   15   164.910 ?  1.514  ns/op (+31.97)
> +BigDecimals.testLargeToEngineeringString  avgt   15    20.826 ?  0.066  ns/op (+212.99)
> +BigDecimals.testSmallToEngineeringString  avgt   15    11.987 ?  0.080  ns/op (+42.53)
> +BigDecimals.testToEngineeringString       avgt   15  1854.372 ? 63.810  ns/op (+0.14)
> 
> 
> The microben covered by fast-path is BigDecimals.testSmallToEngineeringString, highInt + (lowInt < 10 ? ".0" : ".") + lowInt is actually implemented based on StringBuilder and will be much slower than the current baseline.
> 
> Benchmark                                 Mode  Cnt   Score   Error  Units (use StringConcat)
> BigDecimals.testSmallToEngineeringString  avgt   15  41.876 ? 0.182  ns/op

I tested it again and found that the remainder is not slow. This was my wrong impression. I have changed it according to your suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1355834888

From duke at openjdk.org  Wed Oct 11 22:22:13 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 11 Oct 2023 22:22:13 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v2]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
Message-ID: 

On Wed, 11 Oct 2023 09:50:20 GMT, Claes Redestad  wrote:

> I'm not really qualified to review the floating point code. Simplifying away offset and getting rid of the StringBuilderHelper all seem like good improvements, though I think it'd be good if we could either avoid or split out the `JLA` changes.

Keep the duplicate code of StringConcatHelper, or use JLA, or move the code of getCharsLatin1 & stringSize to DecimalDigits (PR #15699). Of the three options, using JLA is the smallest change.

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1758625925

From erikj at openjdk.org  Wed Oct 11 22:28:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 11 Oct 2023 22:28:17 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 21:04:25 GMT, Srinivas Vamsi Parasa  wrote:

>> make/modules/java.base/Lib.gmk line 230:
>> 
>>> 228:       CFLAGS := $(CFLAGS_JDKLIB) $(LIBFFI_CFLAGS), \
>>> 229:       LDFLAGS := $(LDFLAGS_JDKLIB) \
>>> 230:                  $(call SET_SHARED_LIBRARY_ORIGIN), \
>> 
>> If you are going to fix the indentation here, please do it to follow the code conventions for the build system:
>> https://openjdk.org/groups/build/doc/code-conventions.html
>> 
>> 2. If a line must be broken, use four spaces for indentation.
>> 18. Avoid padding internally in a line with spaces to try to align some feature into columns with surrounding lines.
>
> Hi Erik (@erikj79), 
> BUILD_LIBFALLBACKLINKER is from different PR (#13079). If I understand correctly, for LIB_SIMD_SORT, are you suggesting that we don't pad the lines with spaces to align features into columns and instead just use 4 spaces for the indentation after the line break?

I see now that this is an unrelated change. In that case please avoid changing whitespace in unrelated files for this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16124#discussion_r1355842271

From sviswanathan at openjdk.org  Wed Oct 11 22:43:15 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 11 Oct 2023 22:43:15 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 22:25:14 GMT, Erik Joelsson  wrote:

>> Hi Erik (@erikj79), 
>> BUILD_LIBFALLBACKLINKER is from different PR (#13079). If I understand correctly, for LIB_SIMD_SORT, are you suggesting that we don't pad the lines with spaces to align features into columns and instead just use 4 spaces for the indentation after the line break?
>
> I see now that this is an unrelated change. In that case please avoid changing whitespace in unrelated files for this PR.

@erikj79 This space was inadvertently added as part of (https://github.com/openjdk/jdk/pull/14227) and @magicus requested to remove it in this follow-up PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16124#discussion_r1355851543

From vlivanov at openjdk.org  Wed Oct 11 23:17:16 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 11 Oct 2023 23:17:16 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 20:58:23 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert @ForceInline annotations for small array sort methods

Proposed patch has one disadvantage: there's no way to override ergonomics decisions on AMD CPUs and forcibly enable the intrinsic without rebuilding the JVM. 

For many other intrinsics there are flags which enable finer grained control over JVM behavior (e.g., `UseVectorizedHashCodeIntrinsic`). There were some complaints that there are way to many individual flags to control intrinsics, so now there's `-XX:ControlIntrinsic=`, but as of now ergonomics doesn't rely on it to control what intrinsics are enabled/disabled.

It makes sense to let `-XX:ControlIntrinsic=` overrule `VM_Version::is_intel()` check and enable the intrinsics when `AVX512DQ` is supported.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758673497

From vlivanov at openjdk.org  Wed Oct 11 23:28:59 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 11 Oct 2023 23:28:59 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
Message-ID: <8uf8J87AXNXJ8LIMjDLTNt1RjWNkp3579RuzLJXLtoQ=.f6a8ad88-b2c7-4819-abac-02dc1b1daff1@github.com>

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - fix code style and formatting
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>  - change variable names of indexPivot* to pivotIndex*
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>  - Remove the unnecessary exception in single pivot partitioning fallback method
>  - Move functional interfaces close to the associated methods
>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>  - Refactor stub handling to use a generic function for all types
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86

src/java.base/share/classes/java/util/DualPivotQuicksort.java line 157:

> 155:     @ForceInline
> 156:     private static  void sort(Class elemType, A array, long offset, int low, int high, SortOperation so) {
> 157:         so.sort(array, low, high);

I'm late to the party, but how does the fallback implementation work (or is intended to) for off-heap case (null + absolute base address)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1355879308

From vlivanov at openjdk.org  Wed Oct 11 23:29:00 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 11 Oct 2023 23:29:00 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: <8uf8J87AXNXJ8LIMjDLTNt1RjWNkp3579RuzLJXLtoQ=.f6a8ad88-b2c7-4819-abac-02dc1b1daff1@github.com>
References: 
 
 <8uf8J87AXNXJ8LIMjDLTNt1RjWNkp3579RuzLJXLtoQ=.f6a8ad88-b2c7-4819-abac-02dc1b1daff1@github.com>
Message-ID: 

On Wed, 11 Oct 2023 23:25:22 GMT, Vladimir Ivanov  wrote:

>> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - fix code style and formatting
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>>  - change variable names of indexPivot* to pivotIndex*
>>  - Update DualPivotQuicksort.java
>>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>>  - Remove the unnecessary exception in single pivot partitioning fallback method
>>  - Move functional interfaces close to the associated methods
>>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>>  - Refactor stub handling to use a generic function for all types
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86
>
> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 157:
> 
>> 155:     @ForceInline
>> 156:     private static  void sort(Class elemType, A array, long offset, int low, int high, SortOperation so) {
>> 157:         so.sort(array, low, high);
> 
> I'm late to the party, but how does the fallback implementation work (or is intended to) for off-heap case (null + absolute base address)?

Also, for on-heap case the fallback implementation is equivalent to intrinsified case only when offset points at the 0th element of the array.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1355879636

From sviswanathan at openjdk.org  Wed Oct 11 23:41:45 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 11 Oct 2023 23:41:45 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 <8uf8J87AXNXJ8LIMjDLTNt1RjWNkp3579RuzLJXLtoQ=.f6a8ad88-b2c7-4819-abac-02dc1b1daff1@github.com>
 
Message-ID: <-x33S4BZ4LoTAVxqX_JxSgoedY-aC4wtkIc4J_mAo5I=.76da1d0b-8397-4163-b0d5-8c5271cd57c8@github.com>

On Wed, 11 Oct 2023 23:25:30 GMT, Vladimir Ivanov  wrote:

>> src/java.base/share/classes/java/util/DualPivotQuicksort.java line 157:
>> 
>>> 155:     @ForceInline
>>> 156:     private static  void sort(Class elemType, A array, long offset, int low, int high, SortOperation so) {
>>> 157:         so.sort(array, low, high);
>> 
>> I'm late to the party, but how does the fallback implementation work (or is intended to) for off-heap case (null + absolute base address)?
>
> Also, for on-heap case the fallback implementation is equivalent to intrinsified case only when offset points at the 0th element of the array.

@iwanowww Yes, you are late to the party :). The fallback implementation could be similar to the vectorizedMismatch regarding base/offset for non heap case. Please see java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java.
Yes, the fallback implementation for non intrinsic case is kept to be equivalent to what was before the SIMD sort PR. This is done to not affect the fallback performance on other platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1355886081

From sviswanathan at openjdk.org  Wed Oct 11 23:44:15 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 11 Oct 2023 23:44:15 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 11 Oct 2023 23:14:26 GMT, Vladimir Ivanov  wrote:

> Proposed patch has one disadvantage: there's no way to override ergonomics decisions on AMD CPUs and forcibly enable the intrinsic without rebuilding the JVM.
> 
> For many other intrinsics there are flags which enable finer grained control over JVM behavior (e.g., `UseVectorizedHashCodeIntrinsic`). There were some complaints that there are way to many individual flags to control intrinsics, so now there's `-XX:ControlIntrinsic=`, but as of now ergonomics doesn't rely on it to control what intrinsics are enabled/disabled.
> 
> It makes sense to let `-XX:ControlIntrinsic=` overrule `VM_Version::is_intel()` check and enable the intrinsics when `AVX512DQ` is supported.

May be it could be done as part of https://bugs.openjdk.org/browse/JDK-8317976.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758699096

From vlivanov at openjdk.org  Wed Oct 11 23:57:47 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 11 Oct 2023 23:57:47 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: <-x33S4BZ4LoTAVxqX_JxSgoedY-aC4wtkIc4J_mAo5I=.76da1d0b-8397-4163-b0d5-8c5271cd57c8@github.com>
References: 
 
 <8uf8J87AXNXJ8LIMjDLTNt1RjWNkp3579RuzLJXLtoQ=.f6a8ad88-b2c7-4819-abac-02dc1b1daff1@github.com>
 
 <-x33S4BZ4LoTAVxqX_JxSgoedY-aC4wtkIc4J_mAo5I=.76da1d0b-8397-4163-b0d5-8c5271cd57c8@github.com>
Message-ID: 

On Wed, 11 Oct 2023 23:38:05 GMT, Sandhya Viswanathan  wrote:

>> Also, for on-heap case the fallback implementation is equivalent to intrinsified case only when offset points at the 0th element of the array.
>
> @iwanowww Yes, you are late to the party :). The fallback implementation could be similar to the vectorizedMismatch regarding base/offset for non heap case. Please see java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java.
> Yes, the fallback implementation for non intrinsic case is kept to be equivalent to what was before the SIMD sort PR. This is done to not affect the fallback performance on other platforms.

The problem with fallback implementation as it is now is that it doesn't take into account the offset. It's completely broken for off-heap case and works for on-heap case only because the implementation always passes primitive array base offset.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1355894722

From kvn at openjdk.org  Thu Oct 12 00:38:21 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Oct 2023 00:38:21 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 23:40:55 GMT, Sandhya Viswanathan  wrote:

> > It makes sense to let `-XX:ControlIntrinsic=` overrule `VM_Version::is_intel()` check and enable the intrinsics when `AVX512DQ` is supported.
> 
> May be it could be done as part of https://bugs.openjdk.org/browse/JDK-8317976.

It is not easy to do. You need to make sure that you not enable intrinsic by `-XX:ControlIntrinsic=` when it is not supported by hardware. I would say it is separate (second) RFE because we need to test it separately from current Zen 4 issue.

Note, we are not introducing regression to AMD with these changes - code is reverted back to before previous changes [14227](https://github.com/openjdk/jdk/pull/14227). We have some  time to propose patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758737716

From duke at openjdk.org  Thu Oct 12 02:20:49 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Thu, 12 Oct 2023 02:20:49 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 02:54:05 GMT, Shaojin Wen  wrote:

> By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).

src/java.base/share/classes/java/lang/Integer.java line 560:

> 558:         if (radix > Character.MAX_RADIX) {
> 559:             throw NumberFormatException.forMaxRadix(radix);
> 560:         }

It sounds like these methods are now already under the default common inline threshold, but wondering if it would be worthwhile to pull out the radix validation to a separate method.

src/java.base/share/classes/java/lang/NumberFormatException.java line 107:

> 105:     static NumberFormatException forMaxRadix(int radix) {
> 106:         return new NumberFormatException(String.format(
> 107:                 "radix %s greater than Character.MAX_RADIX", radix));

I realize these exception code paths are likely dominated by filling in the stack trace, but I would suggest avoiding `String.format` for these cases where this could just use string concatenation, e.g. see https://github.com/openjdk/jdk/pull/9706

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1354641358
PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1353706211

From duke at openjdk.org  Thu Oct 12 02:20:50 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 02:20:50 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 10 Oct 2023 08:07:37 GMT, Chen Liang  wrote:

>> By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).
>
> src/java.base/share/classes/java/lang/Integer.java line 682:
> 
>> 680:      */
>> 681:     public static int parseInt(String s) throws NumberFormatException {
>> 682:         if (s != null && s.coder() == String.LATIN1) {
> 
> Does this code block actually speed up `parseInt`? I recommend you remove this code block and test `parseInt` and `parseLong` again only with new NumberFormatException factories.

parseInt & parseLong are accelerated by this code, the key code is here

class DecimalDigits {
    public static int digit(byte ch) {
        return DIGITS_LATIN1[ch & 0xFF]; // If remove & 0xFF it won't get faster
    }
}


This optimization can only be done when radix is fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1352076040

From liach at openjdk.org  Thu Oct 12 02:20:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Oct 2023 02:20:50 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 12 Oct 2023 00:06:30 GMT, Shaojin Wen  wrote:

>> src/java.base/share/classes/java/lang/Integer.java line 560:
>> 
>>> 558:         if (radix > Character.MAX_RADIX) {
>>> 559:             throw NumberFormatException.forMaxRadix(radix);
>>> 560:         }
>> 
>> It sounds like these methods are now already under the default common inline threshold, but wondering if it would be worthwhile to pull out the radix validation to a separate method.
>
> Code style should be consistent

He means to pull the `radix< Character,MIN_RADIX` and `radix > Character.MAX_RADIX` shared code in Integer and Long.parseInt (with radix version) to a helper method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1355904991

From duke at openjdk.org  Thu Oct 12 02:20:49 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 02:20:49 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
Message-ID: 

By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).

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

Commit messages:
 - fix from @schlosna 's review
 - Optimization for Integer.parseX & Long.parseX

Changes: https://git.openjdk.org/jdk/pull/16112/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317980
  Stats: 234 lines in 6 files changed: 174 ins; 24 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/16112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16112/head:pull/16112

PR: https://git.openjdk.org/jdk/pull/16112

From duke at openjdk.org  Thu Oct 12 02:20:49 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 02:20:49 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 10:30:26 GMT, David Schlosnagle  wrote:

>> By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).
>
> src/java.base/share/classes/java/lang/Integer.java line 560:
> 
>> 558:         if (radix > Character.MAX_RADIX) {
>> 559:             throw NumberFormatException.forMaxRadix(radix);
>> 560:         }
> 
> It sounds like these methods are now already under the default common inline threshold, but wondering if it would be worthwhile to pull out the radix validation to a separate method.

Code style should be consistent

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1355901164

From liach at openjdk.org  Thu Oct 12 02:20:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Oct 2023 02:20:50 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 02:54:05 GMT, Shaojin Wen  wrote:

> By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).

src/java.base/share/classes/java/lang/Integer.java line 682:

> 680:      */
> 681:     public static int parseInt(String s) throws NumberFormatException {
> 682:         if (s != null && s.coder() == String.LATIN1) {

Does this code block actually speed up `parseInt`? I recommend you remove this code block and test `parseInt` and `parseLong` again only with new NumberFormatException factories.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1351791166

From vlivanov at openjdk.org  Thu Oct 12 02:20:20 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 12 Oct 2023 02:20:20 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 20:58:23 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert @ForceInline annotations for small array sort methods

FTR I'm perfectly fine with handling it separately.

> It is not easy to do. You need to make sure that you not enable intrinsic by -XX:ControlIntrinsic=

There's `VM_Version::is_intrinsic_supported()` introduced specifically for such type of platform-specific checks. `vmIntrinsics::is_intrinsic_available()` takes into account both `ControlIntrinsic`/`DisableIntrinsic` and  `VM_Version::is_intrinsic_supported()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758808390

From duke at openjdk.org  Thu Oct 12 02:20:50 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Thu, 12 Oct 2023 02:20:50 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 00:14:45 GMT, Chen Liang  wrote:

>> Code style should be consistent
>
> He means to pull the `radix< Character,MIN_RADIX` and `radix > Character.MAX_RADIX` shared code in Integer and Long.parseInt (with radix version) to a helper method.

More explicitly I was thinking something like below. 

I do wonder if some of the benchmark tests should cover the exceptional cases. I have seen many systems where attempting to try and parse potentially invalid inputs can hit expensive NumberFormatException fallbacks (though `-XX:+OmitStackTraceInFastThrow` may eventually kick in). [Guava offers `Integer Ints.tryParse(String)`](https://guava.dev/releases/32.1.3-jre/api/docs/com/google/common/primitives/Ints.html#tryParse(java.lang.String)) and similar to avoid the exception overhead at the cost of boxing for happy path of valid `int` and `null` for invalid.


        checkCanParseLength(s);
        checkCanParseRadix(radix);
        int len = s.length();


    private static void checkCanParseLength(String s) {
        if (s == null) {
            throw NumberFormatException.forNull();
        }

        if (s.isEmpty()) { // would be interesting to see if this is equivalent to `s.length() == 0` for happy paths
            throw NumberFormatException.forEmpty();
        }
    }

    private static void checkCanParseRadix(int radix) {
        if (radix < Character.MIN_RADIX) {
            throw NumberFormatException.forMinRadix(radix);
        }

        if (radix > Character.MAX_RADIX) {
            throw NumberFormatException.forMaxRadix(radix);
        }
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1355916625

From duke at openjdk.org  Thu Oct 12 02:27:17 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 02:27:17 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 00:39:27 GMT, David Schlosnagle  wrote:

>> He means to pull the `radix< Character,MIN_RADIX` and `radix > Character.MAX_RADIX` shared code in Integer and Long.parseInt (with radix version) to a helper method.
>
> More explicitly I was thinking something like below. 
> 
> I do wonder if some of the benchmark tests should cover the exceptional cases. I have seen many systems where attempting to try and parse potentially invalid inputs can hit expensive NumberFormatException fallbacks (though `-XX:+OmitStackTraceInFastThrow` may eventually kick in). [Guava offers `Integer Ints.tryParse(String)`](https://guava.dev/releases/32.1.3-jre/api/docs/com/google/common/primitives/Ints.html#tryParse(java.lang.String)) and similar to avoid the exception overhead at the cost of boxing for happy path of valid `int` and `null` for invalid.
> 
> 
>         checkCanParseLength(s);
>         checkCanParseRadix(radix);
>         int len = s.length();
> 
> 
>     private static void checkCanParseLength(String s) {
>         if (s == null) {
>             throw NumberFormatException.forNull();
>         }
> 
>         if (s.isEmpty()) { // would be interesting to see if this is equivalent to `s.length() == 0` for happy paths
>             throw NumberFormatException.forEmpty();
>         }
>     }
> 
>     private static void checkCanParseRadix(int radix) {
>         if (radix < Character.MIN_RADIX) {
>             throw NumberFormatException.forMinRadix(radix);
>         }
> 
>         if (radix > Character.MAX_RADIX) {
>             throw NumberFormatException.forMaxRadix(radix);
>         }
>     }

In addition to FreqInlineSize 325, there are other reasons that affect inlining. If inlining fails, there will be one more method call, making it slower.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1355971785

From duke at openjdk.org  Thu Oct 12 02:20:49 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 02:20:49 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
Message-ID: <2_Z3b1OH1Tm9rJ6u92FlJZLzBSaqp_iQl_fVMvY8Mqk=.e8e037f6-9fb6-4c6a-b999-327f2ccf94a4@github.com>

On Tue, 10 Oct 2023 02:54:05 GMT, Shaojin Wen  wrote:

> By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).

By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.

codeSize 350 bytes -> 260 bytes
public static int parseUnsignedInt(CharSequence s, int beginIndex, int endIndex, int radix)

codeSize 327 bytes -> 283 bytes
public static long parseLong(CharSequence s, int beginIndex, int endIndex, int radix)

codeSize 362 bytes -> 269 bytes
public static long parseUnsignedLong(CharSequence s, int beginIndex, int endIndex, int radix)


Performance numbers running on MacBook M1 Pro:

-Benchmark                              (size)  Mode  Cnt  Score   Error  Units
-Integers.parseInt                         500  avgt   15  2.501 ? 0.028  us/op
-Integers.parseIntCharSequence             500  avgt   15  2.558 ? 0.042  us/op
-Integers.parseUnisgnedIntCharSequence     500  avgt   15  3.883 ? 0.040  us/op
-Integers.parseUnsignedInt                 500  avgt   15  2.266 ? 0.008  us/op
-Longs.parseLong                           500  avgt   15  2.790 ? 0.017  us/op
-Longs.parseLongCharSequence               500  avgt   15  3.779 ? 0.043  us/op
-Longs.parseUnsignedLong                   500  avgt   15  2.421 ? 0.032  us/op
-Longs.parseUnsignedLongCharSequence       500  avgt   15  4.107 ? 0.046  us/op

+Benchmark                              (size)  Mode  Cnt  Score   Error  Units
+Integers.parseInt                         500  avgt   15  2.238 ? 0.017  us/op (+11.76)
+Integers.parseIntCharSequence             500  avgt   15  2.515 ? 0.004  us/op (+1.71)
+Integers.parseUnisgnedIntCharSequence     500  avgt   15  2.274 ? 0.031  us/op (+70.76)
+Integers.parseUnsignedInt                 500  avgt   15  2.265 ? 0.006  us/op (+0.05)
+Longs.parseLong                           500  avgt   15  2.492 ? 0.023  us/op (+11.96)
+Longs.parseLongCharSequence               500  avgt   15  2.807 ? 0.031  us/op (+34.63)
+Longs.parseUnsignedLong                   500  avgt   15  2.404 ? 0.047  us/op (+0.71)
+Longs.parseUnsignedLongCharSequence       500  avgt   15  2.379 ? 0.025  us/op (+72.64)

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

PR Comment: https://git.openjdk.org/jdk/pull/16112#issuecomment-1754259343

From duke at openjdk.org  Thu Oct 12 02:20:50 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 02:20:50 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 10 Oct 2023 10:22:18 GMT, Chen Liang  wrote:

>> parseInt & parseLong are accelerated by this code, the key code is here
>> 
>> class DecimalDigits {
>>     public static int digit(byte ch) {
>>         return DIGITS_LATIN1[ch & 0xFF]; // If remove & 0xFF it won't get faster
>>     }
>> }
>> 
>> 
>> This optimization can only be done when radix is fixed.
>
> You are right, JIT profiles are based on bytecode, and by not sharing the code path with generic-radix parseInt, JIT can better optimize the base-10 path.
> 
> In addition, is `(digit = value[i++] - '0') >= 0 && digit <= 9` slower than a table lookup? Don't think you actually need that digit table.

-Benchmark          (size)  Mode  Cnt  Score   Error  Units (baseline)
-Integers.parseInt     500  avgt   15  2.474 ? 0.014  us/op

+Benchmark          (size)  Mode  Cnt  Score   Error  Units (non-lookup table)
+Integers.parseInt     500  avgt   15  2.376 ? 0.018  us/op

+Benchmark          (size)  Mode  Cnt  Score   Error  Units (current f6828ff)
+Integers.parseInt     500  avgt   15  2.267 ? 0.011  us/op

(digit = value[i++] - '0') >= 0 && digit <= 9 slower than a table lookup (current version f6828ff), but faster than base line

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1352837006

From liach at openjdk.org  Thu Oct 12 02:20:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Oct 2023 02:20:50 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 10 Oct 2023 10:03:52 GMT, Shaojin Wen  wrote:

>> src/java.base/share/classes/java/lang/Integer.java line 682:
>> 
>>> 680:      */
>>> 681:     public static int parseInt(String s) throws NumberFormatException {
>>> 682:         if (s != null && s.coder() == String.LATIN1) {
>> 
>> Does this code block actually speed up `parseInt`? I recommend you remove this code block and test `parseInt` and `parseLong` again only with new NumberFormatException factories.
>
> parseInt & parseLong are accelerated by this code, the key code is here
> 
> class DecimalDigits {
>     public static int digit(byte ch) {
>         return DIGITS_LATIN1[ch & 0xFF]; // If remove & 0xFF it won't get faster
>     }
> }
> 
> 
> This optimization can only be done when radix is fixed.

You are right, JIT profiles are based on bytecode, and by not sharing the code path with generic-radix parseInt, JIT can better optimize the base-10 path.

In addition, is `(digit = value[i++] - '0') >= 0 && digit <= 9` slower than a table lookup? Don't think you actually need that digit table.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1352107910

From duke at openjdk.org  Thu Oct 12 02:54:17 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 02:54:17 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 02:24:20 GMT, Shaojin Wen  wrote:

>> More explicitly I was thinking something like below. 
>> 
>> I do wonder if some of the benchmark tests should cover the exceptional cases. I have seen many systems where attempting to try and parse potentially invalid inputs can hit expensive NumberFormatException fallbacks (though `-XX:+OmitStackTraceInFastThrow` may eventually kick in). [Guava offers `Integer Ints.tryParse(String)`](https://guava.dev/releases/32.1.3-jre/api/docs/com/google/common/primitives/Ints.html#tryParse(java.lang.String)) and similar to avoid the exception overhead at the cost of boxing for happy path of valid `int` and `null` for invalid.
>> 
>> 
>>         checkCanParseLength(s);
>>         checkCanParseRadix(radix);
>>         int len = s.length();
>> 
>> 
>>     private static void checkCanParseLength(String s) {
>>         if (s == null) {
>>             throw NumberFormatException.forNull();
>>         }
>> 
>>         if (s.isEmpty()) { // would be interesting to see if this is equivalent to `s.length() == 0` for happy paths
>>             throw NumberFormatException.forEmpty();
>>         }
>>     }
>> 
>>     private static void checkCanParseRadix(int radix) {
>>         if (radix < Character.MIN_RADIX) {
>>             throw NumberFormatException.forMinRadix(radix);
>>         }
>> 
>>         if (radix > Character.MAX_RADIX) {
>>             throw NumberFormatException.forMaxRadix(radix);
>>         }
>>     }
>
> In addition to FreqInlineSize 325, there are other reasons that affect inlining. If inlining fails, there will be one more method call, making it slower.

This PR does not optimize the scenario where inputting illegal values leads to exceptions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1355987122

From duke at openjdk.org  Thu Oct 12 03:47:18 2023
From: duke at openjdk.org (Danny Thomas)
Date: Thu, 12 Oct 2023 03:47:18 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 20:58:23 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert @ForceInline annotations for small array sort methods

At least on Saphire Rapids the [emulation suggested here](https://github.com/natmaurice/x86-simd-sort/commit/41d03b2d8f3b62a2ee6a3a97a8da7f193a407026) only imposes a 6% penalty for `intSort`, while also mitigating the performance issue on Zen 4.


Configuration summary:
* Name:           linux-x86_64-server-release
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'cds compiler1 compiler2 epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc'
* OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
* Version string: 22-internal-adhoc.nfsuper.jdk (22-internal)
* Source date:    1697078366 (2023-10-12T02:39:26Z)

Tools summary:
* Boot JDK:       openjdk version "21" 2023-09-19 OpenJDK Runtime Environment Zulu21.28+86-SA (build 21+35) OpenJDK 64-Bit Server VM Zulu21.28+86-SA (build 21+35, mixed mode, sharing) (at /usr/lib/jvm/zulu-21-amd64)
* Toolchain:      gcc (GNU Compiler Collection)
* C Compiler:     Version 11.4.0 (at /usr/bin/gcc)
* C++ Compiler:   Version 11.4.0 (at /usr/bin/g++)


https://github.com/openjdk/jdk/compare/master...DanielThomas:jdk:dannyt/emulate-compressstoreu?expand=1

## Intel(R) Xeon(R) Platinum 8488C - Current


Benchmark            (size)  Mode  Cnt     Score     Error  Units
ArraysSort.intSort       10  avgt    3     0.043 ?   0.006  us/op
ArraysSort.intSort       25  avgt    3     0.082 ?   0.002  us/op
ArraysSort.intSort       50  avgt    3     0.205 ?   0.022  us/op
ArraysSort.intSort       75  avgt    3     0.394 ?   0.048  us/op
ArraysSort.intSort      100  avgt    3     0.625 ?   0.003  us/op
ArraysSort.intSort     1000  avgt    3     5.759 ?   1.111  us/op
ArraysSort.intSort    10000  avgt    3    51.680 ?   3.568  us/op
ArraysSort.intSort   100000  avgt    3   777.339 ?  25.809  us/op
ArraysSort.intSort  1000000  avgt    3  8848.261 ? 954.475  us/op


## Intel(R) Xeon(R) Platinum 8488C - Emulated


Benchmark            (size)  Mode  Cnt     Score     Error  Units
ArraysSort.intSort       10  avgt    3     0.046 ?   0.002  us/op
ArraysSort.intSort       25  avgt    3     0.083 ?   0.004  us/op
ArraysSort.intSort       50  avgt    3     0.214 ?   0.022  us/op
ArraysSort.intSort       75  avgt    3     0.411 ?   0.038  us/op
ArraysSort.intSort      100  avgt    3     0.658 ?   0.022  us/op
ArraysSort.intSort     1000  avgt    3     6.411 ?   0.497  us/op
ArraysSort.intSort    10000  avgt    3    55.996 ?   3.155  us/op
ArraysSort.intSort   100000  avgt    3   822.805 ?  40.223  us/op
ArraysSort.intSort  1000000  avgt    3  9487.974 ? 216.146  us/op


## Intel(R) Xeon(R) Platinum 8488C - Baseline


Benchmark            (size)  Mode  Cnt      Score      Error  Units
ArraysSort.intSort       10  avgt    3      0.047 ?    0.006  us/op
ArraysSort.intSort       25  avgt    3      0.099 ?    0.022  us/op
ArraysSort.intSort       50  avgt    3      0.249 ?    0.024  us/op
ArraysSort.intSort       75  avgt    3      0.438 ?    0.046  us/op
ArraysSort.intSort      100  avgt    3      0.590 ?    0.079  us/op
ArraysSort.intSort     1000  avgt    3      8.384 ?    1.852  us/op
ArraysSort.intSort    10000  avgt    3    435.589 ?   23.647  us/op
ArraysSort.intSort   100000  avgt    3   5380.658 ?  491.435  us/op
ArraysSort.intSort  1000000  avgt    3  63857.189 ? 2746.106  us/op


## AMD EPYC 9R14 - Emulated


$ make test TEST="micro:java.lang.ArraysSort.intSort"

Benchmark            (size)  Mode  Cnt     Score     Error  Units
ArraysSort.intSort       10  avgt    3     0.032 ?   0.001  us/op
ArraysSort.intSort       25  avgt    3     0.067 ?   0.002  us/op
ArraysSort.intSort       50  avgt    3     0.196 ?   0.002  us/op
ArraysSort.intSort       75  avgt    3     0.429 ?   0.046  us/op
ArraysSort.intSort      100  avgt    3     0.614 ?   0.025  us/op
ArraysSort.intSort     1000  avgt    3     6.500 ?   0.084  us/op
ArraysSort.intSort    10000  avgt    3    55.620 ?   0.943  us/op
ArraysSort.intSort   100000  avgt    3   669.347 ?  75.432  us/op
ArraysSort.intSort  1000000  avgt    3  9459.001 ? 201.298  us/op
Finished running test 'micro:java.lang.ArraysSort.intSort'


## AMD EPYC 9R14 - Baseline


$ make test TEST="micro:java.lang.ArraysSort.intSort" MICRO="VM_OPTIONS=-XX:UseAVX=2"

Benchmark            (size)  Mode  Cnt      Score      Error  Units
ArraysSort.intSort       10  avgt    3      0.035 ?    0.016  us/op
ArraysSort.intSort       25  avgt    3      0.091 ?    0.009  us/op
ArraysSort.intSort       50  avgt    3      0.245 ?    0.002  us/op
ArraysSort.intSort       75  avgt    3      0.412 ?    0.004  us/op
ArraysSort.intSort      100  avgt    3      0.531 ?    0.003  us/op
ArraysSort.intSort     1000  avgt    3      8.803 ?    0.609  us/op
ArraysSort.intSort    10000  avgt    3    254.413 ?  153.004  us/op
ArraysSort.intSort   100000  avgt    3   4485.811 ?   17.517  us/op
ArraysSort.intSort  1000000  avgt    3  56552.132 ? 3124.280  us/op

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758865865

From duke at openjdk.org  Thu Oct 12 04:45:24 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 12 Oct 2023 04:45:24 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 12 Oct 2023 04:41:37 GMT, Vladimir Kozlov  wrote:

> My tier1-3,xcomp testing for v04 passed. I am integrating these changes. Lets continue discussion about changes for AMD in https://bugs.openjdk.org/browse/JDK-8317976.

Thank you, Vladimir!

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1758901615

From kvn at openjdk.org  Thu Oct 12 04:45:23 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Oct 2023 04:45:23 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 20:58:23 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
>> The proposed changes are:
>> 
>> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
>> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
>> 3) Minor changes in Javadoc strings
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert @ForceInline annotations for small array sort methods

My tier1-3,xcomp testing for v04 passed. I am integrating these changes.
Lets continue discussion about changes for AMD in  https://bugs.openjdk.org/browse/JDK-8317976.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16124#pullrequestreview-1673014053

From duke at openjdk.org  Thu Oct 12 04:48:41 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 12 Oct 2023 04:48:41 GMT
Subject: Integrated: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort()
 PR
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 16:44:03 GMT, Srinivas Vamsi Parasa  wrote:

> The goal of this PR is to address the follow-up comments to the SIMD accelerated sort PR (#14227) which implemented AVX512 intrinsics for Arrays.sort() methods.
> The proposed changes are:
> 
> 1) Restriction of the AVX512 sort acceleration to only Intel CPUs. A performance regression (due to micro-architectural differences) was reported for AMD Zen4 CPUs in the comments section of PR.
> 2) Addressing the build failure due to a bug in GCC 12 (which was fixed in version 12.3.1). The details of the bug are at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
> 3) Minor changes in Javadoc strings

This pull request has now been integrated.

Changeset: 2edf9c3f
Author:    vamsi-parasa 
Committer: Vladimir Kozlov 
URL:       https://git.openjdk.org/jdk/commit/2edf9c3f1e968779c6e92b3e25d780db68ace5cc
Stats:     20 lines in 4 files changed: 10 ins; 1 del; 9 mod

8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR

Reviewed-by: jbhateja, kvn, ihse, sviswanathan

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

PR: https://git.openjdk.org/jdk/pull/16124

From duke at openjdk.org  Thu Oct 12 06:04:12 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 06:04:12 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 9 Oct 2023 23:21:57 GMT, Shaojin Wen  wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No longer localize printed numbers

# Summary
Keep the behavior of String.format('%tF') when printing LocalDate consistent with the behavior of DateTimeFormatter.ISO_LOCAL_DATE.


# Problem
1. When using String.format('%tF', localDate), use get(ChronoField.YEAR_OF_ERA). When the value range is not [0,9999], the behavior is inconsistent with DateTimeFormatter.ISO_LOCAL_DATE.format.
2. When String.format('%tF', localDate), Locale will be processed, which is inconsistent with the standard.

* the year value range [-?, -1] changes:
``` java
String.format("%tF", LocalDate.of(-10000, 1, 1))
// String.format 10001-01-01
// DateTimeFormatter  -99999-01-01


* the year value range [10000, +?] changes:

String.format("%tF", LocalDate.of(10000, 1, 1)):
// String.format 10000-01-01
// DateTimeFormatter.format  +10000-01-01
And the "%tF" format no longer handles Locale when printing numbers.



Locale.setDefault(
        Locale.forLanguageTag("th-TH-u-nu-thai"));
String.format("%tF", LocalDate.of(2001, 1, 1));
// String.format ????-??-??
// DateTimeFormatter.ISO_LOCAL_DATE.format 2001-01-01


# Solution
1. When String.format('%tF', localDate) uses ChronoField.YEAR instead of ChronoField.YEAR_OF_ERA, when year > 9999, the prefix is added with '+'
2. And don't use Locale to print numbers.


# Specification
* [-?, -1000]

String.format("%tF", LocalDate.of(-10000, 1, 1))
// -99999-01-01


The year value range [-999, -1], padded to 4 digits

String.format("%tF", LocalDate.of(-1, 1, 1))
// -0001-01-01



The year value range [1, 9999], padded to 4 digits

String.format("%tF", LocalDate.of(1, 1, 1))
// 0001-01-01


* The year value range [10000, -?], prefix prints '+'

String.format("%tF", LocalDate.of(10000, 1, 1))
// +10000-01-01


#  Risk
1. When String.format('%tF') processes LocalDate/ZonedDateTime/OffsetDateTime, if the value range of year is not in [0-9999], the output will be different from before.
2. When the Locale of String.format('%tF') is "th-TH-u-nu-thai", the printed result is different from before.

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1758959859

From duke at openjdk.org  Thu Oct 12 06:20:16 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 06:20:16 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 6 Oct 2023 14:20:13 GMT, Claes Redestad  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update full name
>
> FWIW I'll not review or sponsor any PRs that use `ByteArrayLittleEndian` for trivial `byte[]` writes until there's been a thorough analysis of why this helps and shown that JITs can't be expected to generate code that is as optimal.

@cl4es Can it be integrated?

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1758978716

From stuefe at openjdk.org  Thu Oct 12 06:53:17 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Oct 2023 06:53:17 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 10:57:24 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cosmetic changes 2

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 69:

> 67: 
> 68:         if (arraySize != parentArraySize) {
> 69:             JNU_ThrowIllegalArgumentException(env, "array sizes not equal");

proposal: "Parent pid array must have the same length as result pid array"

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 89:

> 87: 
> 88:     do { // Block to break out of on Exception
> 89:         pids = (*env)->GetLongArrayElements(env, jarray, NULL);

Nit, I'd move these invocations of GLAE into the initialization block and remove the outer loop. I see what you do here, the outer block gives you a reliable jumping point to get cleanup in case of an error. But I would just use a goto cleanup label. That's clearer and allows you to handle initialization in one place.

Proposal for initialization:


if (jparentArray != null) {
  - check size is same as primary array, if wrong throw + goto cleanup
  - ppids = GLAE
} else {
  - if input pid is 0, throw an error too, since for "get all processes mode"
      we need the parent array. Throw + goto cleanup.
}
// same for times array

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 112:

> 110:                 jlong startTime = 0L;
> 111: 
> 112:                 /* skip files that aren't numbers */

As @MBaesken pointed out, this comment is obsolete.

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 114:

> 112:                 /* skip files that aren't numbers */
> 113:                 pid_t childpid = (pid_t) ProcessBuffer[i].pi_pid;
> 114:                 if ((int) childpid <= 0) {

Can this even happen? Negative pids are group pids, I don't think getprocs returns group pids.

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 120:

> 118:                 // Get the parent pid, and start time
> 119:                 ppid = (pid_t) ProcessBuffer[i].pi_ppid;
> 120:                 startTime = ((jlong) ProcessBuffer[i].pi_start) *1000;

nit: space before 1000

src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 121:

> 119:                 ppid = (pid_t) ProcessBuffer[i].pi_ppid;
> 120:                 startTime = ((jlong) ProcessBuffer[i].pi_start) *1000;
> 121:                 if (ppid >= 0 && (pid == 0 || ppid == pid)) {

I think the first condition is always true. You can remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1356131767
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1356134470
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1356137028
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1356137647
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1356137949
PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1356141163

From pminborg at openjdk.org  Thu Oct 12 07:18:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Oct 2023 07:18:22 GMT
Subject: Integrated: 8317873: Add @sealedGraph to IllegalFormatException
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 Oct 2023 07:59:24 GMT, Per Minborg  wrote:

> This PR proposes to add @sealedGraph to `IllegalFormatException`

This pull request has now been integrated.

Changeset: eca6ea43
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/eca6ea43d085a68b9b9760e732275175cb1b0de3
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8317873: Add @sealedGraph to IllegalFormatException

Reviewed-by: naoto, iris

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

PR: https://git.openjdk.org/jdk/pull/16140

From duke at openjdk.org  Thu Oct 12 07:47:43 2023
From: duke at openjdk.org (Agnibho Hom Chowdhury)
Date: Thu, 12 Oct 2023 07:47:43 GMT
Subject: RFR: JDK-8249832: java/util/zip/DataDescriptorSignatureMissing.java
 uses @ignore w/o bug-id
Message-ID: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>

Please review this PR as a fix of [JDK-8249832](https://bugs.openjdk.org/browse/JDK-8249832). I have added the bug with after @ignore annotation.

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

Commit messages:
 - added bug-id with @ignore

Changes: https://git.openjdk.org/jdk/pull/16073/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16073&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8249832
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16073/head:pull/16073

PR: https://git.openjdk.org/jdk/pull/16073

From pminborg at openjdk.org  Thu Oct 12 07:57:24 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Oct 2023 07:57:24 GMT
Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to slightly improve some iterators of `AbstractMap`:
> 
> * Declare two fields `final`
> * Use distinct classes rather than anonymous classes

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15615/files
  - new: https://git.openjdk.org/jdk/pull/15615/files/1057e166..ceafcaf5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15615&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15615&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15615.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15615/head:pull/15615

PR: https://git.openjdk.org/jdk/pull/15615

From pminborg at openjdk.org  Thu Oct 12 07:57:26 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Oct 2023 07:57:26 GMT
Subject: Integrated: 8315850: Improve AbstractMap anonymous Iterator classes
In-Reply-To: 
References: 
Message-ID: <-kBEkeHUAOjr80zImxe8O43I7P-ec1NXIsvC6-3L5PM=.810e67d0-4493-45e6-b6ba-642398f1335c@github.com>

On Thu, 7 Sep 2023 11:48:51 GMT, Per Minborg  wrote:

> This PR proposes to slightly improve some iterators of `AbstractMap`:
> 
> * Declare two fields `final`
> * Use distinct classes rather than anonymous classes

This pull request has now been integrated.

Changeset: d95b548c
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/d95b548c78d2c504ccc3044f434f83e5c8237b0e
Stats:     48 lines in 1 file changed: 16 ins; 28 del; 4 mod

8315850: Improve AbstractMap anonymous Iterator classes

Reviewed-by: liach, smarks

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

PR: https://git.openjdk.org/jdk/pull/15615

From mbaesken at openjdk.org  Thu Oct 12 08:09:44 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 08:09:44 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native java.base
 coding
Message-ID: 

There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.

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

Commit messages:
 - JDK-8317959

Changes: https://git.openjdk.org/jdk/pull/16160/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317959
  Stats: 26 lines in 4 files changed: 24 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16160.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16160/head:pull/16160

PR: https://git.openjdk.org/jdk/pull/16160

From aturbanov at openjdk.org  Thu Oct 12 08:14:16 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 12 Oct 2023 08:14:16 GMT
Subject: RFR: 8316144: Remove unused field
 jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element._Depth
In-Reply-To: 
References: 
Message-ID: 

On Tue, 12 Sep 2023 20:04:54 GMT, Andrey Turbanov  wrote:

> A field `short _Depth` in the `jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element` class is unused and can be removed.

@JoeWang-Java can I have a review, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/15692#issuecomment-1759141491

From hgreule at openjdk.org  Thu Oct 12 08:50:10 2023
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 12 Oct 2023 08:50:10 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 00:39:27 GMT, David Schlosnagle  wrote:

>> He means to pull the `radix< Character,MIN_RADIX` and `radix > Character.MAX_RADIX` shared code in Integer and Long.parseInt (with radix version) to a helper method.
>
> More explicitly I was thinking something like below. 
> 
> I do wonder if some of the benchmark tests should cover the exceptional cases. I have seen many systems where attempting to try and parse potentially invalid inputs can hit expensive NumberFormatException fallbacks (though `-XX:+OmitStackTraceInFastThrow` may eventually kick in). [Guava offers `Integer Ints.tryParse(String)`](https://guava.dev/releases/32.1.3-jre/api/docs/com/google/common/primitives/Ints.html#tryParse(java.lang.String)) and similar to avoid the exception overhead at the cost of boxing for happy path of valid `int` and `null` for invalid.
> 
> 
>         checkCanParseLength(s);
>         checkCanParseRadix(radix);
>         int len = s.length();
> 
> 
>     private static void checkCanParseLength(String s) {
>         if (s == null) {
>             throw NumberFormatException.forNull();
>         }
> 
>         if (s.isEmpty()) { // would be interesting to see if this is equivalent to `s.length() == 0` for happy paths
>             throw NumberFormatException.forEmpty();
>         }
>     }
> 
>     private static void checkCanParseRadix(int radix) {
>         if (radix < Character.MIN_RADIX) {
>             throw NumberFormatException.forMinRadix(radix);
>         }
> 
>         if (radix > Character.MAX_RADIX) {
>             throw NumberFormatException.forMaxRadix(radix);
>         }
>     }

While only optimizing the fast path is a good idea, I think it is important to make sure there is no regression on the slow path - as @schlosna pointed out, it's a common way to check if a string can be converted to an int.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1356495786

From liach at openjdk.org  Thu Oct 12 09:01:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Oct 2023 09:01:12 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 08:47:09 GMT, Hannes Greule  wrote:

>> More explicitly I was thinking something like below. 
>> 
>> I do wonder if some of the benchmark tests should cover the exceptional cases. I have seen many systems where attempting to try and parse potentially invalid inputs can hit expensive NumberFormatException fallbacks (though `-XX:+OmitStackTraceInFastThrow` may eventually kick in). [Guava offers `Integer Ints.tryParse(String)`](https://guava.dev/releases/32.1.3-jre/api/docs/com/google/common/primitives/Ints.html#tryParse(java.lang.String)) and similar to avoid the exception overhead at the cost of boxing for happy path of valid `int` and `null` for invalid.
>> 
>> 
>>         checkCanParseLength(s);
>>         checkCanParseRadix(radix);
>>         int len = s.length();
>> 
>> 
>>     private static void checkCanParseLength(String s) {
>>         if (s == null) {
>>             throw NumberFormatException.forNull();
>>         }
>> 
>>         if (s.isEmpty()) { // would be interesting to see if this is equivalent to `s.length() == 0` for happy paths
>>             throw NumberFormatException.forEmpty();
>>         }
>>     }
>> 
>>     private static void checkCanParseRadix(int radix) {
>>         if (radix < Character.MIN_RADIX) {
>>             throw NumberFormatException.forMinRadix(radix);
>>         }
>> 
>>         if (radix > Character.MAX_RADIX) {
>>             throw NumberFormatException.forMaxRadix(radix);
>>         }
>>     }
>
> While only optimizing the fast path is a good idea, I think it is important to make sure there is no regression on the slow path - as @schlosna pointed out, it's a common way to check if a string can be converted to an int.

This patch should have little impact on exception-path performance. Remember String concatenation is done with StringBuilder in java.base, so changing formatter to that might have some performance difference. However, the main overhead of exception was from creation and initialization of stack trace.; the new code was just copies of the existing generic-radix parseInt, except it has a more efficient way to obtain digits via a table.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1356510156

From alanb at openjdk.org  Thu Oct 12 09:11:26 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 09:11:26 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v49]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 13:07:08 GMT, Doug Lea 
 wrote:

>> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
>> 
>> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup

This is a large update to fix a really hard problem. I've been testing and running with these changes on and off for several months and they are stable now. The code is very dense and hard to read but the description at a top is very good/helpful.

The API changes are okay.  The source compatibility issue with dropping the override of the invokeAll combinator is unfortunate but combined with everything else it means that FJP now implements the ES contract and can work as a replacement for say TPE.

So I think this changes are good to go.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14301#pullrequestreview-1673674131

From rgiulietti at openjdk.org  Thu Oct 12 09:13:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 12 Oct 2023 09:13:15 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 08:58:18 GMT, Chen Liang  wrote:

>> While only optimizing the fast path is a good idea, I think it is important to make sure there is no regression on the slow path - as @schlosna pointed out, it's a common way to check if a string can be converted to an int.
>
> This patch should have little impact on exception-path performance. Remember String concatenation is done with StringBuilder in java.base, so changing formatter to that might have some performance difference. However, the main overhead of exception was from creation and initialization of stack trace.; the new code was just copies of the existing generic-radix parseInt, except it has a more efficient way to obtain digits via a table.

Let's not forget that `Character.digit()` has a pretty decent fast path for Latin1, including a 256 bytes lookup-table.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1356526163

From duke at openjdk.org  Thu Oct 12 09:22:11 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 09:22:11 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 09:10:30 GMT, Raffaello Giulietti  wrote:

>> This patch should have little impact on exception-path performance. Remember String concatenation is done with StringBuilder in java.base, so changing formatter to that might have some performance difference. However, the main overhead of exception was from creation and initialization of stack trace.; the new code was just copies of the existing generic-radix parseInt, except it has a more efficient way to obtain digits via a table.
>
> Let's not forget that `Character.digit()` has a pretty decent fast path for Latin1, including a 256 bytes lookup-table.

CharacterDataLatin1.digit is for multi-radix, and the performance when radix = 10 is not good enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1356538024

From jkern at openjdk.org  Thu Oct 12 09:30:09 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 12 Oct 2023 09:30:09 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v5]
In-Reply-To: 
References: 
Message-ID: 

> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.

Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:

  revise of the function comment and some other proposals

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16051/files
  - new: https://git.openjdk.org/jdk/pull/16051/files/986ff9a0..55e20035

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16051&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16051&range=03-04

  Stats: 40 lines in 2 files changed: 18 ins; 8 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/16051.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16051/head:pull/16051

PR: https://git.openjdk.org/jdk/pull/16051

From mchhipa at openjdk.org  Thu Oct 12 09:31:14 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 12 Oct 2023 09:31:14 GMT
Subject: RFR: JDK-8249832:
 java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id
In-Reply-To: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
References: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
Message-ID: 

On Fri, 6 Oct 2023 12:43:02 GMT, Agnibho Hom Chowdhury  wrote:

> Please review this PR as a fix of [JDK-8249832](https://bugs.openjdk.org/browse/JDK-8249832). I have added the bug with after @ignore annotation.

Looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/16073#issuecomment-1759259625

From jkern at openjdk.org  Thu Oct 12 09:37:15 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 12 Oct 2023 09:37:15 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 12 Oct 2023 09:30:09 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revise of the function comment and some other proposals

I revised the function comment on base of Rogers and Thomas proposals adding some more information.
I also followed some of Thomas and Matthias proposals.

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1759268748

From jkern at openjdk.org  Thu Oct 12 09:37:19 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 12 Oct 2023 09:37:19 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 12 Oct 2023 06:30:33 GMT, Thomas Stuefe  wrote:

>> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cosmetic changes 2
>
> src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 89:
> 
>> 87: 
>> 88:     do { // Block to break out of on Exception
>> 89:         pids = (*env)->GetLongArrayElements(env, jarray, NULL);
> 
> Nit, I'd move these invocations of GLAE into the initialization block and remove the outer loop. I see what you do here, the outer block gives you a reliable jumping point to get cleanup in case of an error. But I would just use a goto cleanup label. That's clearer and allows you to handle initialization in one place.
> 
> Proposal for initialization:
> 
> 
> if (jparentArray != null) {
>   - check size is same as primary array, if wrong throw + goto cleanup
>   - ppids = GLAE
> } else {
>   - if input pid is 0, throw an error too, since for "get all processes mode"
>       we need the parent array. Throw + goto cleanup.
> }
> // same for times array

hmm? As I already mentioned I do not want to change the structure of the function with this pr. This can be done by someone else for macos, linux and aix in parallel.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1356556894

From duke at openjdk.org  Thu Oct 12 09:58:19 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 09:58:19 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 09:19:35 GMT, Shaojin Wen  wrote:

>> Let's not forget that `Character.digit()` has a pretty decent fast path for Latin1, including a 256 bytes lookup-table.
>
> CharacterDataLatin1.digit is for multi-radix, and the performance when radix = 10 is not good enough.

If we reuse CharacterDataLatin1#DIGITS, the performance will be slower, the performance numbers are as follows


class CharacterDataLatin1 {
    static int digit(int ch) {
        int value = DIGITS[ch & 0xFF];
        return (value >= 0 && value < 10) ? value : -1;
    }
}



Benchmark          (size)  Mode  Cnt  Score   Error  Units (baseline)
Integers.parseInt     500  avgt   15  2.614 ? 0.003  us/op

Benchmark          (size)  Mode  Cnt  Score   Error  Units (use CharacterDataLatin1#digit)
Integers.parseInt     500  avgt   15  2.399 ? 0.008  us/op

Benchmark          (size)  Mode  Cnt  Score   Error  Units (c3e878a)
Integers.parseInt     500  avgt   15  2.251 ? 0.010  us/op

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1356582378

From liach at openjdk.org  Thu Oct 12 10:06:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Oct 2023 10:06:11 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 09:55:15 GMT, Shaojin Wen  wrote:

>> CharacterDataLatin1.digit is for multi-radix, and the performance when radix = 10 is not good enough.
>
> If we reuse CharacterDataLatin1#DIGITS, the performance will be slower, the performance numbers are as follows
> 
> 
> class CharacterDataLatin1 {
>     static int digit(int ch) {
>         int value = DIGITS[ch & 0xFF];
>         return (value >= 0 && value < 10) ? value : -1;
>     }
> }
> 
> 
> 
> Benchmark          (size)  Mode  Cnt  Score   Error  Units (baseline)
> Integers.parseInt     500  avgt   15  2.614 ? 0.003  us/op
> 
> Benchmark          (size)  Mode  Cnt  Score   Error  Units (use CharacterDataLatin1#digit)
> Integers.parseInt     500  avgt   15  2.399 ? 0.008  us/op
> 
> Benchmark          (size)  Mode  Cnt  Score   Error  Units (c3e878a)
> Integers.parseInt     500  avgt   15  2.251 ? 0.010  us/op

Maybe there's something wrong with the `value < radix` check that JIT cannot efficiently optimize it (so `digit <= 9` has a similar performance to `value < 10` in loops). We might have to check the hotspot assembly to find out the reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16112#discussion_r1356591852

From ihse at openjdk.org  Thu Oct 12 10:27:37 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Oct 2023 10:27:37 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 07:17:04 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed obsolete exports from BuildMicrobenchmark.gmk

make/test/BuildMicrobenchmark.gmk line 99:

> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
> 98:         --add-exports java.base/sun.invoke.util=ALL-UNNAMED \
> 99:         --add-exports java.base/jdk.internal.classfile.impl=ALL-UNNAMED \

Just checking: do we really need `jdk.internal.classfile.impl`? (It might have been added in by someone a bit sloppily just adding all jdk.internal.classfile modules.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356612666

From stuefe at openjdk.org  Thu Oct 12 10:29:18 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Oct 2023 10:29:18 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: <_IGWtoGZjMlVGMLW6O2CgQK9YpnjvoiLXYvd_J3WScU=.de884b3a-31af-4e63-be99-adfe8d2a6d17@github.com>

On Thu, 12 Oct 2023 09:33:24 GMT, Joachim Kern  wrote:

>> src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 89:
>> 
>>> 87: 
>>> 88:     do { // Block to break out of on Exception
>>> 89:         pids = (*env)->GetLongArrayElements(env, jarray, NULL);
>> 
>> Nit, I'd move these invocations of GLAE into the initialization block and remove the outer loop. I see what you do here, the outer block gives you a reliable jumping point to get cleanup in case of an error. But I would just use a goto cleanup label. That's clearer and allows you to handle initialization in one place.
>> 
>> Proposal for initialization:
>> 
>> 
>> if (jparentArray != null) {
>>   - check size is same as primary array, if wrong throw + goto cleanup
>>   - ppids = GLAE
>> } else {
>>   - if input pid is 0, throw an error too, since for "get all processes mode"
>>       we need the parent array. Throw + goto cleanup.
>> }
>> // same for times array
>
> hmm? As I already mentioned I do not want to change the structure of the function with this pr. This can be done by someone else for macos, linux and aix in parallel.

If someone reworks the code, you would have to counter-check the code anyway since nobody else has AIX machines around to build and test. So I'd just do it to save some cycles. But I leave it up to you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16051#discussion_r1356614666

From mchhipa at openjdk.org  Thu Oct 12 10:32:24 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 12 Oct 2023 10:32:24 GMT
Subject: RFR: JDK-8249832:
 java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id
In-Reply-To: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
References: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
Message-ID: <9ls8cZqdJBBRe2BUKofJ1VWzDzUfOmEJzCRFXoPvRmg=.7206f743-f9ac-4b8f-9373-9175e333595c@github.com>

On Fri, 6 Oct 2023 12:43:02 GMT, Agnibho Hom Chowdhury  wrote:

> Please review this PR as a fix of [JDK-8249832](https://bugs.openjdk.org/browse/JDK-8249832). I have added the bug with after @ignore annotation.

test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 1:

> 1: /*

Could you please update the Copyright year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16073#discussion_r1356618161

From asotona at openjdk.org  Thu Oct 12 10:43:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 12 Oct 2023 10:43:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: <0g69xIyi7-edOQ35XZBQhNazpZKiDSouTo2SJ0zNOAU=.4d70694f-d75e-4347-bb3d-00a2efab680a@github.com>

On Thu, 12 Oct 2023 10:23:56 GMT, Magnus Ihse Bursie  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed obsolete exports from BuildMicrobenchmark.gmk
>
> make/test/BuildMicrobenchmark.gmk line 99:
> 
>> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
>> 98:         --add-exports java.base/sun.invoke.util=ALL-UNNAMED \
>> 99:         --add-exports java.base/jdk.internal.classfile.impl=ALL-UNNAMED \
> 
> Just checking: do we really need `jdk.internal.classfile.impl`? (It might have been added in by someone a bit sloppily just adding all jdk.internal.classfile modules.)

One of the benchmarks is focused on stack maps generator, which is not directly exposed through the API. We can remove this one and keep just the API-based benchmarks if it an issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356629635

From ihse at openjdk.org  Thu Oct 12 10:51:31 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Oct 2023 10:51:31 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: <0g69xIyi7-edOQ35XZBQhNazpZKiDSouTo2SJ0zNOAU=.4d70694f-d75e-4347-bb3d-00a2efab680a@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
 <0g69xIyi7-edOQ35XZBQhNazpZKiDSouTo2SJ0zNOAU=.4d70694f-d75e-4347-bb3d-00a2efab680a@github.com>
Message-ID: 

On Thu, 12 Oct 2023 10:40:03 GMT, Adam Sotona  wrote:

>> make/test/BuildMicrobenchmark.gmk line 99:
>> 
>>> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
>>> 98:         --add-exports java.base/sun.invoke.util=ALL-UNNAMED \
>>> 99:         --add-exports java.base/jdk.internal.classfile.impl=ALL-UNNAMED \
>> 
>> Just checking: do we really need `jdk.internal.classfile.impl`? (It might have been added in by someone a bit sloppily just adding all jdk.internal.classfile modules.)
>
> One of the benchmarks is focused on stack maps generator, which is not directly exposed through the API. We can remove this one and keep just the API-based benchmarks if it an issue.

No, it is not an issue per se. If we need to benchmark internal code, that's totally fine. I just wanted to check so we did not pass unnecessary arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356638601

From mcimadamore at openjdk.org  Thu Oct 12 11:18:47 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Oct 2023 11:18:47 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 07:17:04 GMT, Adam Sotona  wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed obsolete exports from BuildMicrobenchmark.gmk

src/java.base/share/classes/java/lang/classfile/package-info.java line 259:

> 257:  * the classfile building process.
> 258:  * 

> 259:  * Syntax validation is applied during symbolic descriptors construction.

I would drop `syntax` - and just use `Validation`

src/java.base/share/classes/java/lang/classfile/package-info.java line 265:

> 263:  * 

> 264:  * Using symbolic descriptors assures the right serial form selection by
> 265:  * the ClassFile API library. For example a class name is stored in its internal

I find this comment still very hard to parse. There is a lot of terminology here thrown to the reader (internal form, class descriptor, serial form), and very little explanation of which is which. I get the general idea that, if I use a `ClassDesc`, the API will take care to convert that to the right form, depending on the context - but it feels there's too much text, and too few examples to ground that text.

src/java.base/share/classes/java/lang/classfile/package-info.java line 278:

> 276:  * constant pool entries to avoid any form of syntax validation or conversion.
> 277:  * Constant pool entries can be constructed from raw values, with no additional
> 278:  * syntactic checks, conversions or validations. In the following example is

`syntactic checks` and `validation` feel the same thing. If there's some validation that is materially different from a syntactic check that is important for the reader to grasp, then spell it out. Otherwise leave it out and remain more general.

src/java.base/share/classes/java/lang/classfile/package-info.java line 401:

> 399:  *
> 400:  * 
Transformation handling of unknown classfile elements

> 401:  * Future JDK releases may introduce new classfile elements, not known at the

Maybe this is more direct/punchy?

`Custom classfile transformations might be unaware of classfile elements introduced by future JDK releases.`

src/java.base/share/classes/java/lang/classfile/package-info.java line 403:

> 401:  * Future JDK releases may introduce new classfile elements, not known at the
> 402:  * development time of a custom transformation code.
> 403:  * To achieve deterministic stability of transformations running on future JDK

This para seems largely redundant. Perhaps you can merge with the next? E.g. "To achieve deterministic stability, classfile transforms interested ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356662662
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356661342
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356663577
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356666225
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356667448

From rriggs at openjdk.org  Thu Oct 12 13:59:14 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 12 Oct 2023 13:59:14 GMT
Subject: RFR: JDK-8315026: java/lang/ProcessHandle/TreeTest.java fails
 intermittent on AIX in TreeTest.test5 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 12 Oct 2023 09:30:09 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revise of the function comment and some other proposals

Looks good. Thanks for the additional comments.

Keeping the code structure parallel to the original will make maintaining it easier.
"Goto" is still considered harmful. IMHO

BTW, someday this can/should be replaced with all java code using Panama. ;)

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16051#pullrequestreview-1674245057

From redestad at openjdk.org  Thu Oct 12 14:03:38 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Oct 2023 14:03:38 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 17:06:08 GMT, Shaojin Wen  wrote:

>> In the improvement of @cl4es PR #15591, the advantages of non-lookup-table were discussed.
>> 
>> But if the input is byte[], using lookup table can improve performance.
>> 
>> For HexFormat#formatHex(Appendable, byte[]) and HexFormat#formatHex(byte[]), If the length of byte[] is larger, the performance of table lookup will be improved more obviously.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not ByteArrayLittleEndian

Yes, I think this looks fine. Thank you for your patience.

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1759644549

From vklang at openjdk.org  Thu Oct 12 14:11:20 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 12 Oct 2023 14:11:20 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v49]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 13:07:08 GMT, Doug Lea 
 wrote:

>> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
>> 
>> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3153:

> 3151:     public  ForkJoinTask submit(Callable task) {
> 3152:         ForkJoinTask t =
> 3153:             (Thread.currentThread() instanceof ForkJoinWorkerThread) ?

@DougLea Won't we need to check if the submitting thread belongs to the same pool here?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3324:

> 3322:                 poolSubmit(true, f);
> 3323:             }
> 3324:             for (int i = futures.size() - 1; i >= 0; --i)

@DougLea Might not be necessary for performance, but using an ArrayDeque and using `pollLast()` might be cleaner?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1356855770
PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1356859056

From erikj at openjdk.org  Thu Oct 12 14:13:33 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 12 Oct 2023 14:13:33 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v4]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 11 Oct 2023 22:40:20 GMT, Sandhya Viswanathan  wrote:

>> I see now that this is an unrelated change. In that case please avoid changing whitespace in unrelated files for this PR.
>
> @erikj79 This space was inadvertently added as part of (https://github.com/openjdk/jdk/pull/14227) and @magicus requested to remove it in this follow-up PR.

Ok, I missed that, never mind me then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16124#discussion_r1356808569

From mbaesken at openjdk.org  Thu Oct 12 14:16:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 14:16:55 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: 
References: 
Message-ID: 

> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  doabort in check method in case no memory can be allocated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16160/files
  - new: https://git.openjdk.org/jdk/pull/16160/files/24fbb465..109b13c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16160&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16160&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16160.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16160/head:pull/16160

PR: https://git.openjdk.org/jdk/pull/16160

From alanb at openjdk.org  Thu Oct 12 14:16:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 14:16:57 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 12 Oct 2023 12:17:27 GMT, Matthias Baesken  wrote:

>> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doabort in check method in case no memory can be allocated

src/java.base/windows/native/libjli/cmdtoargs.c line 327:

> 325:         // "pgmname" rest of cmdline ie. pgmname + 2 double quotes + space + cmdline from windows
> 326:         char* cptr = (char*) malloc(strlen(argv[0]) + sizeof(char) * 3 + strlen(cmdline) + 1);
> 327:         if (cptr == NULL) return false;

This doesn't look right, I think it has no choice but to print an error and doabort..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16160#discussion_r1356709874

From mbaesken at openjdk.org  Thu Oct 12 14:16:57 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Oct 2023 14:16:57 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 12 Oct 2023 12:00:19 GMT, Alan Bateman  wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   doabort in check method in case no memory can be allocated
>
> src/java.base/windows/native/libjli/cmdtoargs.c line 327:
> 
>> 325:         // "pgmname" rest of cmdline ie. pgmname + 2 double quotes + space + cmdline from windows
>> 326:         char* cptr = (char*) malloc(strlen(argv[0]) + sizeof(char) * 3 + strlen(cmdline) + 1);
>> 327:         if (cptr == NULL) return false;
> 
> This doesn't look right, I think it has no choice but to print an error and doabort..

Hi Alan, I adjusted this part of the coding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16160#discussion_r1356728099

From duke at openjdk.org  Thu Oct 12 14:18:16 2023
From: duke at openjdk.org (Agnibho Hom Chowdhury)
Date: Thu, 12 Oct 2023 14:18:16 GMT
Subject: RFR: JDK-8249832:
 java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id [v2]
In-Reply-To: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
References: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
Message-ID: 

> Please review this PR as a fix of [JDK-8249832](https://bugs.openjdk.org/browse/JDK-8249832). I have added the bug with after @ignore annotation.

Agnibho Hom Chowdhury has updated the pull request incrementally with one additional commit since the last revision:

  upadted copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16073/files
  - new: https://git.openjdk.org/jdk/pull/16073/files/0aba4101..a5b9a2fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16073&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16073&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16073/head:pull/16073

PR: https://git.openjdk.org/jdk/pull/16073

From duke at openjdk.org  Thu Oct 12 14:18:29 2023
From: duke at openjdk.org (Agnibho Hom Chowdhury)
Date: Thu, 12 Oct 2023 14:18:29 GMT
Subject: RFR: JDK-8249832:
 java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id [v2]
In-Reply-To: <9ls8cZqdJBBRe2BUKofJ1VWzDzUfOmEJzCRFXoPvRmg=.7206f743-f9ac-4b8f-9373-9175e333595c@github.com>
References: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
 <9ls8cZqdJBBRe2BUKofJ1VWzDzUfOmEJzCRFXoPvRmg=.7206f743-f9ac-4b8f-9373-9175e333595c@github.com>
Message-ID: 

On Thu, 12 Oct 2023 10:29:31 GMT, Mahendra Chhipa  wrote:

>> Agnibho Hom Chowdhury has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   upadted copyright year
>
> test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 1:
> 
>> 1: /*
> 
> Could you please update the Copyright year.

Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16073#discussion_r1356708811

From rriggs at openjdk.org  Thu Oct 12 14:27:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 12 Oct 2023 14:27:20 GMT
Subject: RFR: JDK-8315026: ProcessHandle implementation listing processes
 on AIX should use getprocs64 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 12 Oct 2023 09:30:09 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revise of the function comment and some other proposals

Also, since 'fixing' this issue resulting in a very different implementation, I'd suggest changing the title of the bug and PR to something like:
`ProcessHandle implementation listing processes on AIX should use getproc64.`

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

PR Comment: https://git.openjdk.org/jdk/pull/16051#issuecomment-1759661752

From rriggs at openjdk.org  Thu Oct 12 14:27:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 12 Oct 2023 14:27:30 GMT
Subject: Integrated: 8317956: Make jdk.internal.util.Architecture current
 architecture final
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 Oct 2023 13:25:14 GMT, Roger Riggs  wrote:

> The static for the current architecture should be final to allow some optimizations.

This pull request has now been integrated.

Changeset: c1f698d3
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/c1f698d38bb251941598af5a82a1a230282b718d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8317956: Make jdk.internal.util.Architecture current architecture final

Reviewed-by: pminborg, redestad, bpb

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

PR: https://git.openjdk.org/jdk/pull/16150

From vklang at openjdk.org  Thu Oct 12 14:27:52 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 12 Oct 2023 14:27:52 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v49]
In-Reply-To: 
References: 
 
Message-ID: <-T8jFCFkMktTAbrBKswTaaI8Mz0RyE8ZSUWrc15ajCU=.106e7723-adb9-40a5-8685-fdeffadad77c@github.com>

On Wed, 11 Oct 2023 13:07:08 GMT, Doug Lea 
 wrote:

>> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
>> 
>> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup

I gave the PR a final review just now, there was a few questions which might not warrant any changes.

I concur with the assessment that these changes should be good to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/14301#issuecomment-1759683705

From duke at openjdk.org  Thu Oct 12 14:27:58 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 14:27:58 GMT
Subject: Integrated: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: 
References: 
Message-ID: 

On Fri, 15 Sep 2023 18:04:29 GMT, Shaojin Wen  wrote:

> In the improvement of @cl4es PR #15591, the advantages of non-lookup-table were discussed.
> 
> But if the input is byte[], using lookup table can improve performance.
> 
> For HexFormat#formatHex(Appendable, byte[]) and HexFormat#formatHex(byte[]), If the length of byte[] is larger, the performance of table lookup will be improved more obviously.

This pull request has now been integrated.

Changeset: 93554314
Author:    wenshao 
Committer: Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/935543146b23f22a73e14c6789cf73db7c3d466b
Stats:     82 lines in 3 files changed: 55 ins; 13 del; 14 mod

8316426: Optimization for HexFormat.formatHex

Reviewed-by: liach, rriggs

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

PR: https://git.openjdk.org/jdk/pull/15768

From asotona at openjdk.org  Thu Oct 12 15:28:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 12 Oct 2023 15:28:46 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v20]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  package info javadoc improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/37371955..edc13bac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=18-19

  Stats: 24 lines in 1 file changed: 0 ins; 10 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Thu Oct 12 15:28:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 12 Oct 2023 15:28:55 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Thu, 12 Oct 2023 11:11:10 GMT, Maurizio Cimadamore  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed obsolete exports from BuildMicrobenchmark.gmk
>
> src/java.base/share/classes/java/lang/classfile/package-info.java line 259:
> 
>> 257:  * the classfile building process.
>> 258:  * 

>> 259:  * Syntax validation is applied during symbolic descriptors construction.
> 
> I would drop `syntax` - and just use `Validation`

Yes, applied, thanks.

> src/java.base/share/classes/java/lang/classfile/package-info.java line 265:
> 
>> 263:  * 

>> 264:  * Using symbolic descriptors assures the right serial form selection by
>> 265:  * the ClassFile API library. For example a class name is stored in its internal
> 
> I find this comment still very hard to parse. There is a lot of terminology here thrown to the reader (internal form, class descriptor, serial form), and very little explanation of which is which. I get the general idea that, if I use a `ClassDesc`, the API will take care to convert that to the right form, depending on the context - but it feels there's too much text, and too few examples to ground that text.

I've tried to rephrase the paragraph and simplify it, thanks.

> src/java.base/share/classes/java/lang/classfile/package-info.java line 278:
> 
>> 276:  * constant pool entries to avoid any form of syntax validation or conversion.
>> 277:  * Constant pool entries can be constructed from raw values, with no additional
>> 278:  * syntactic checks, conversions or validations. In the following example is
> 
> `syntactic checks` and `validation` feel the same thing. If there's some validation that is materially different from a syntactic check that is important for the reader to grasp, then spell it out. Otherwise leave it out and remain more general.

Right, fixed, thanks.

> src/java.base/share/classes/java/lang/classfile/package-info.java line 401:
> 
>> 399:  *
>> 400:  * 
Transformation handling of unknown classfile elements

>> 401:  * Future JDK releases may introduce new classfile elements, not known at the
> 
> Maybe this is more direct/punchy?
> 
> `Custom classfile transformations might be unaware of classfile elements introduced by future JDK releases.`

More clear, thanks.

> src/java.base/share/classes/java/lang/classfile/package-info.java line 403:
> 
>> 401:  * Future JDK releases may introduce new classfile elements, not known at the
>> 402:  * development time of a custom transformation code.
>> 403:  * To achieve deterministic stability of transformations running on future JDK
> 
> This para seems largely redundant. Perhaps you can merge with the next? E.g. "To achieve deterministic stability, classfile transforms interested ..."

Yes, merged according to the suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356989724
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356989504
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356989983
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356990585
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356991173

From stuefe at openjdk.org  Thu Oct 12 16:02:35 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Oct 2023 16:02:35 GMT
Subject: RFR: JDK-8315026: ProcessHandle implementation listing processes
 on AIX should use getprocs64 [v5]
In-Reply-To: 
References: 
 
Message-ID: <9ziaeu7ERc1sSWd3e12rYLOdi8Cn4IPsawVjS90Sse4=.cb001f4e-79ed-4778-971b-83c751ebb4df@github.com>

On Thu, 12 Oct 2023 09:30:09 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revise of the function comment and some other proposals

ok

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16051#pullrequestreview-1674558899

From alanb at openjdk.org  Thu Oct 12 16:24:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Oct 2023 16:24:12 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 12 Oct 2023 14:16:55 GMT, Matthias Baesken  wrote:

>> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doabort in check method in case no memory can be allocated

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16160#pullrequestreview-1674603470

From bpb at openjdk.org  Thu Oct 12 16:49:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Oct 2023 16:49:15 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 12 Oct 2023 14:16:55 GMT, Matthias Baesken  wrote:

>> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doabort in check method in case no memory can be allocated

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16160#pullrequestreview-1674660076

From psandoz at openjdk.org  Thu Oct 12 16:52:59 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 12 Oct 2023 16:52:59 GMT
Subject: RFR: 8317763: Follow-up to AVX512 intrinsics for Arrays.sort() PR
 [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 12 Oct 2023 03:44:28 GMT, Danny Thomas  wrote:

> At least on Saphire Rapids the [emulation suggested here](https://github.com/natmaurice/x86-simd-sort/commit/41d03b2d8f3b62a2ee6a3a97a8da7f193a407026) only imposes a 6% penalty for `intSort`, while also mitigating the performance issue on Zen 4.

Thanks for testing this out, this seems a good solution to explore. 

Is there is a way to `ifdef` switching on the CPU vendor? otherwise we could probably set a flag in the build script based of the CPU vendor, which may be more robust if different compilers are used.

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

PR Comment: https://git.openjdk.org/jdk/pull/16124#issuecomment-1759992778

From dl at openjdk.org  Thu Oct 12 16:56:22 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 12 Oct 2023 16:56:22 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v49]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 12 Oct 2023 13:46:01 GMT, Viktor Klang  wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More cleanup
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3153:
> 
>> 3151:     public  ForkJoinTask submit(Callable task) {
>> 3152:         ForkJoinTask t =
>> 3153:             (Thread.currentThread() instanceof ForkJoinWorkerThread) ?
> 
> @DougLea Won't we need to check if the submitting thread belongs to the same pool here?

No, but I can imagine this being the subject of a Puzzler someday, because either choice might be unexpected by someone! To maximize compatibility wrt incompatible specs (initial FJ and ES), calls to submit from workers are by default noninterruptible, even if they are client calls into another pool. The opposite choice might be more defensible but could break existing code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1357116787

From dl at openjdk.org  Thu Oct 12 17:09:54 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 12 Oct 2023 17:09:54 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v49]
In-Reply-To: 
References: 
 
 
Message-ID: <1p0Xl3DvkPgKuwOAX9vtiYm4qVuCOIXB9ldOPcNFXS8=.cfbf69c4-a7fd-4f2c-a49a-41957ec85dc5@github.com>

On Thu, 12 Oct 2023 13:48:23 GMT, Viktor Klang  wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More cleanup
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3324:
> 
>> 3322:                 poolSubmit(true, f);
>> 3323:             }
>> 3324:             for (int i = futures.size() - 1; i >= 0; --i)
> 
> @DougLea Might not be necessary for performance, but using an ArrayDeque and using `pollLast()` might be cleaner?

This was a good enough idea that I started doing it until realizing/remembering that ArrayDeque doesn't implement List so can't be used here (without making a copy). Oh well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1357139728

From lancea at openjdk.org  Thu Oct 12 17:19:34 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 12 Oct 2023 17:19:34 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 11 Oct 2023 19:27:46 GMT, Joe Wang  wrote:

> Thanks for the update.
> 
> I'm not sure it's necessary to repeat tests with Base64 input. I think Daniel's comment was that the data can be optionally base64-encoded into a string, not that the tests needed to be duplicated.
> 
> The generatePseudoCodeFor... methods in the Util class can be consolidated too.

Yes it does look like there is duplication where the tests are run using a byte array which represents the serialized object and a second time using a Base64 representation.  We do not need both as the intent of the original test is to validate that the serialized object can be read across the JDK versions

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

PR Comment: https://git.openjdk.org/jdk/pull/13537#issuecomment-1760036070

From vklang at openjdk.org  Thu Oct 12 17:42:20 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 12 Oct 2023 17:42:20 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v49]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 12 Oct 2023 16:53:12 GMT, Doug Lea 
 wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3153:
>> 
>>> 3151:     public  ForkJoinTask submit(Callable task) {
>>> 3152:         ForkJoinTask t =
>>> 3153:             (Thread.currentThread() instanceof ForkJoinWorkerThread) ?
>> 
>> @DougLea Won't we need to check if the submitting thread belongs to the same pool here?
>
> No, but I can imagine this being the subject of a Puzzler someday, because either choice might be unexpected by someone! To maximize compatibility wrt incompatible specs (initial FJ and ES), calls to submit from workers are by default noninterruptible, even if they are client calls into another pool. The opposite choice might be more defensible but could break existing code.

@DougLea Ok, that's good to know. ?

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3324:
>> 
>>> 3322:                 poolSubmit(true, f);
>>> 3323:             }
>>> 3324:             for (int i = futures.size() - 1; i >= 0; --i)
>> 
>> @DougLea Might not be necessary for performance, but using an ArrayDeque and using `pollLast()` might be cleaner?
>
> This was a good enough idea that I started doing it until realizing/remembering that ArrayDeque doesn't implement List so can't be used here (without making a copy). Oh well.

@DougLea Ouch?I completely missed that it is also returned. Apologies :(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1357174453
PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1357172338

From vromero at openjdk.org  Thu Oct 12 18:15:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Oct 2023 18:15:32 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 45:

> 43:     private ExactConversionsSupport() { }
> 44: 
> 45:      /** Exactness method from int to byte

nit: there seems to be an indentation issue in these javadoc, the subsequent lines should be aligned with the first one. What I see in other javadocs is that we don't write in the first line after the `/**` and instead the javadoc starts in the subsequent line.

side: would it make sense to generate this file mechanically? seems like a great candidate for that

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357212078

From redestad at openjdk.org  Thu Oct 12 19:32:17 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Oct 2023 19:32:17 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v2]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
 
Message-ID: <-UONQmxASFBojIbBNYtLHVDpp4j1hwJ9SgymR9HyQlM=.ad307a39-f3d7-485f-b5e4-a597b8e7e6b8@github.com>

On Wed, 11 Oct 2023 22:19:29 GMT, Shaojin Wen  wrote:

> Keep the duplicate code of StringConcatHelper, or use JLA, or move the code of getCharsLatin1 & stringSize to DecimalDigits (PR #15699). Of the three options, using JLA is the smallest change.

Adding methods to JLA also adds a maintenance burden by exposing methods and internal details that we prefer not to expose. 

Explicit `String` concat performs poorly mainly since ISC is disabled for the java.base module. We could, however, explicitly invoke the `StringConcatFactory` and pull out the resulting `MethodHandle`:


diff --git a/src/java.base/share/classes/java/math/BigDecimal.java b/src/java.base/share/classes/java/math/BigDecimal.java
index 3163b2ffadb..b4edbb131d9 100644
--- a/src/java.base/share/classes/java/math/BigDecimal.java
+++ b/src/java.base/share/classes/java/math/BigDecimal.java
@@ -30,6 +30,12 @@
 package java.math;
 
 import static java.math.BigInteger.LONG_MASK;
+
+import java.lang.invoke.CallSite;
+import java.lang.invoke.MethodHandle;
+import java.lang.invoke.MethodHandles;
+import java.lang.invoke.MethodType;
+import java.lang.invoke.StringConcatFactory;
 import java.nio.charset.CharacterCodingException;
 import java.nio.charset.StandardCharsets;
 import java.io.IOException;
@@ -4146,6 +4152,23 @@ public BigDecimal ulp() {
         return BigDecimal.valueOf(1, this.scale(), 1);
     }
 
+    private static class ConcatHelper {
+        private static final MethodHandle INT_DOT_CHAR_CHAR;
+
+        static {
+            try {
+                CallSite site = StringConcatFactory.makeConcatWithConstants(
+                        MethodHandles.lookup(),
+                        "scale2",
+                        MethodType.methodType(String.class, int.class, char.class, char.class),
+                        "\u0001.\u0001\u0001");
+                INT_DOT_CHAR_CHAR = site.dynamicInvoker();
+            } catch (Exception e) {
+                throw new Error("Bootstrap error", e);
+            }
+        }
+    }
+
     /**
      * Lay out this {@code BigDecimal} into a {@code char[]} array.
      * The Java 1.2 equivalent to this was called {@code getValueString}.
@@ -4164,18 +4187,12 @@ private String layoutChars(boolean sci) {
             intCompact >= 0 && intCompact < Integer.MAX_VALUE) {
             // currency fast path
             int highInt = (int)intCompact / 100;
-            int highIntSize = JLA.stringSize(highInt);
-            byte[] buf = new byte[highIntSize + 3];
-            JLA.getCharsLatin1(highInt, highIntSize, buf);
-            buf[highIntSize] = '.';
-            DecimalDigits.writeDigitPairLatin1(
-                    buf,
-                    highIntSize + 1,
-                    (int) intCompact % 100);
+            int lowInt = (int)intCompact - highInt * 100;
+            char pair = (char)DecimalDigits.digitPair(lowInt);
             try {
-                return JLA.newStringNoRepl(buf, StandardCharsets.ISO_8859_1);
-            } catch (CharacterCodingException e) {
-                throw new AssertionError(e);
+                return (String)ConcatHelper.INT_DOT_CHAR_CHAR.invokeExact(highInt, (char)(pair & 0xff), (char)(pair >> 8));
+            } catch (Throwable e) {
+                throw new RuntimeException(e);
             }
         }


This is equivalent to `return "" + highInt + '.' + (char)(pair & 0xff) + (char)(pair >> 8);` (if `BigDecimal.java` would have been compiled without `-XDstringConcat=inline`) and produces code that is as fast or even slightly faster in my tests:

Name                                     Cnt     Base   Error      Test    Error   Unit  Change
BigDecimals.testSmallToEngineeringString  15   11,703 ? 0,017    10,667 ?  0,058  ns/op   1,10x (p = 0,000*)
  :gc.alloc.rate                             4530,180 ? 6,688  4970,132 ? 26,973 MB/sec   1,10x (p = 0,000*)
  :gc.alloc.rate.norm                          55,600 ? 0,000    55,600 ?  0,000   B/op   1,00x (p = 0,000 )
  :gc.count                                   228,000           226,000          counts
  :gc.time                                    131,000           130,000              ms
  * = significant

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1760247214

From redestad at openjdk.org  Thu Oct 12 19:48:19 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 12 Oct 2023 19:48:19 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v4]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: <9ckG9p3xhmNt-ffd4hZeLwLMB4WE1YWIF8c_i5bTi6U=.badd81e0-dd24-40b7-89a4-fa64a9b552bc@github.com>

On Wed, 11 Oct 2023 21:46:04 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @cl4es 's review

Yes, explicitly calling into `StringConcatFactory` and invoking MHs is cumbersome. Just putting it out there as an alternative that works based on current public API. 

It might also be possible to evolve the decision to compile all of java.base with `-XDstringConcat=inline` to instead only do that for a subset of the most core classes. We could then just do `return "" + highInt + '.' + (char)(pair & 0xff) + (char)(pair >> 8);` and get the same performance.

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1760268835

From dcubed at openjdk.org  Thu Oct 12 19:48:26 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 12 Oct 2023 19:48:26 GMT
Subject: RFR: 8318038: ProblemList
 runtime/CompressedOops/CompressedClassPointers.java on two platforms
Message-ID: <6KnmrG9N-X6jzHWabOgejQJYXAk09T9yEW4GW_QRyIc=.770cdcb5-c864-4dcc-a02d-1824d875a972@github.com>

Trivial ProblemListing for some tests:

[JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms
[JDK-8318040](https://bugs.openjdk.org/browse/JDK-8318040) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64
[JDK-8318042](https://bugs.openjdk.org/browse/JDK-8318042) ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC

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

Commit messages:
 - 8318042: ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC
 - 8318040: ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64
 - 8318038: ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms

Changes: https://git.openjdk.org/jdk/pull/16172/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318038
  Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16172/head:pull/16172

PR: https://git.openjdk.org/jdk/pull/16172

From jvernee at openjdk.org  Thu Oct 12 19:53:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Oct 2023 19:53:54 GMT
Subject: Integrated: 8312522: Implementation of Foreign Function & Memory API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee  wrote:

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

This pull request has now been integrated.

Changeset: 32ac72c3
Author:    Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/32ac72c3d35138f5253e4defc948304ac3ea1b53
Stats:     4468 lines in 263 files changed: 2211 ins; 1196 del; 1061 mod

8312522: Implementation of Foreign Function & Memory API

Co-authored-by: Maurizio Cimadamore 
Co-authored-by: Jorn Vernee 
Co-authored-by: Per Minborg 
Reviewed-by: dholmes, psandoz, mcimadamore, alanb

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

PR: https://git.openjdk.org/jdk/pull/15103

From azvegint at openjdk.org  Thu Oct 12 19:58:15 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 12 Oct 2023 19:58:15 GMT
Subject: RFR: 8318038: ProblemList
 runtime/CompressedOops/CompressedClassPointers.java on two platforms
In-Reply-To: <6KnmrG9N-X6jzHWabOgejQJYXAk09T9yEW4GW_QRyIc=.770cdcb5-c864-4dcc-a02d-1824d875a972@github.com>
References: <6KnmrG9N-X6jzHWabOgejQJYXAk09T9yEW4GW_QRyIc=.770cdcb5-c864-4dcc-a02d-1824d875a972@github.com>
Message-ID: 

On Thu, 12 Oct 2023 19:26:10 GMT, Daniel D. Daugherty  wrote:

> Trivial ProblemListing for some tests:
> 
> [JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms
> [JDK-8318040](https://bugs.openjdk.org/browse/JDK-8318040) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64
> [JDK-8318042](https://bugs.openjdk.org/browse/JDK-8318042) ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16172#pullrequestreview-1675071104

From rriggs at openjdk.org  Thu Oct 12 19:58:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 12 Oct 2023 19:58:15 GMT
Subject: RFR: 8318038: ProblemList
 runtime/CompressedOops/CompressedClassPointers.java on two platforms
In-Reply-To: <6KnmrG9N-X6jzHWabOgejQJYXAk09T9yEW4GW_QRyIc=.770cdcb5-c864-4dcc-a02d-1824d875a972@github.com>
References: <6KnmrG9N-X6jzHWabOgejQJYXAk09T9yEW4GW_QRyIc=.770cdcb5-c864-4dcc-a02d-1824d875a972@github.com>
Message-ID: 

On Thu, 12 Oct 2023 19:26:10 GMT, Daniel D. Daugherty  wrote:

> Trivial ProblemListing for some tests:
> 
> [JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms
> [JDK-8318040](https://bugs.openjdk.org/browse/JDK-8318040) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64
> [JDK-8318042](https://bugs.openjdk.org/browse/JDK-8318042) ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16172#pullrequestreview-1675068382

From dcubed at openjdk.org  Thu Oct 12 20:02:17 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 12 Oct 2023 20:02:17 GMT
Subject: RFR: 8318038: ProblemList
 runtime/CompressedOops/CompressedClassPointers.java on two platforms
In-Reply-To: 
References: <6KnmrG9N-X6jzHWabOgejQJYXAk09T9yEW4GW_QRyIc=.770cdcb5-c864-4dcc-a02d-1824d875a972@github.com>
 
Message-ID: 

On Thu, 12 Oct 2023 19:54:17 GMT, Roger Riggs  wrote:

>> Trivial ProblemListing for some tests:
>> 
>> [JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms
>> [JDK-8318040](https://bugs.openjdk.org/browse/JDK-8318040) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64
>> [JDK-8318042](https://bugs.openjdk.org/browse/JDK-8318042) ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs and @azvegint - Thanks for the fast reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/16172#issuecomment-1760285310

From dcubed at openjdk.org  Thu Oct 12 20:05:25 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 12 Oct 2023 20:05:25 GMT
Subject: Integrated: 8318038: ProblemList
 runtime/CompressedOops/CompressedClassPointers.java on two platforms
In-Reply-To: <6KnmrG9N-X6jzHWabOgejQJYXAk09T9yEW4GW_QRyIc=.770cdcb5-c864-4dcc-a02d-1824d875a972@github.com>
References: <6KnmrG9N-X6jzHWabOgejQJYXAk09T9yEW4GW_QRyIc=.770cdcb5-c864-4dcc-a02d-1824d875a972@github.com>
Message-ID: 

On Thu, 12 Oct 2023 19:26:10 GMT, Daniel D. Daugherty  wrote:

> Trivial ProblemListing for some tests:
> 
> [JDK-8318038](https://bugs.openjdk.org/browse/JDK-8318038) ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms
> [JDK-8318040](https://bugs.openjdk.org/browse/JDK-8318040) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64
> [JDK-8318042](https://bugs.openjdk.org/browse/JDK-8318042) ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC

This pull request has now been integrated.

Changeset: 0983b548
Author:    Daniel D. Daugherty 
URL:       https://git.openjdk.org/jdk/commit/0983b54866d7118bb54c87fa3b2260c863376a92
Stats:     5 lines in 2 files changed: 5 ins; 0 del; 0 mod

8318038: ProblemList runtime/CompressedOops/CompressedClassPointers.java on two platforms
8318040: ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006/TestDescription.java on macosx-aarch64
8318042: ProblemList java/nio/channels/vthread/BlockingChannelOps.java#direct-register with GenZGC

Reviewed-by: rriggs, azvegint

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

PR: https://git.openjdk.org/jdk/pull/16172

From jvernee at openjdk.org  Thu Oct 12 20:17:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Oct 2023 20:17:09 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline)
Message-ID: 

Port of: https://github.com/openjdk/panama-foreign/pull/898

Original PR body:

> 
> This patch addresses some issues with `MemorySegment.Scope::equals`. More specifically, when two segments are created from the same array/buffer, their underlying scope should be equal, but currently it is not, which is confusing.
> 
> This patch addesses that by adding a new subclass of `GlobalSession` (`HeapSession`) whose `equals`/`hashcode` methods are defined in terms of the heap reference it wraps. Note that the reference is deduped on construction - that is, we always try to find the "bottom" refrence that we should try to keep alive with the session, and we use that for comparisons (which avoid issues when comparing buffer slices and views).
> 
> As part of the changes, this patch also adds more javadoc on `MemorySegment.Scope` to document how equality works. And, this patch also makes all zero-length memory segments associate with the same "native" scope. This is a scope that is always alive, but is not the global scope (not to confuse with segments created by the global arena). While what the implementation does today is technically correct (a new fresh scope is returned with each new ZLMS), it seems also overkill given that the scope associated with segments originated outside Java code is not very interesting - if users really care about lifetime of such segments they should override the scope with `MemorySegment::reinterpret`. This leads to some changes in the javadoc of other methods where I replaced `fresh scope that is always alive` with just `scope that is always alive`, to avoid suggesting that a new scope should be created each time.

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

Commit messages:
 - add M's javadoc rrefinements
 - 8317050: Scope should reflect lifetime of underying resource

Changes: https://git.openjdk.org/jdk/pull/16126/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317819
  Stats: 268 lines in 12 files changed: 210 ins; 13 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/16126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16126/head:pull/16126

PR: https://git.openjdk.org/jdk/pull/16126

From jvernee at openjdk.org  Thu Oct 12 20:17:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Oct 2023 20:17:10 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 17:17:00 GMT, Jorn Vernee  wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/898
> 
> Original PR body:
> 
>> 
>> This patch addresses some issues with `MemorySegment.Scope::equals`. More specifically, when two segments are created from the same array/buffer, their underlying scope should be equal, but currently it is not, which is confusing.
>> 
>> This patch addesses that by adding a new subclass of `GlobalSession` (`HeapSession`) whose `equals`/`hashcode` methods are defined in terms of the heap reference it wraps. Note that the reference is deduped on construction - that is, we always try to find the "bottom" refrence that we should try to keep alive with the session, and we use that for comparisons (which avoid issues when comparing buffer slices and views).
>> 
>> As part of the changes, this patch also adds more javadoc on `MemorySegment.Scope` to document how equality works. And, this patch also makes all zero-length memory segments associate with the same "native" scope. This is a scope that is always alive, but is not the global scope (not to confuse with segments created by the global arena). While what the implementation does today is technically correct (a new fresh scope is returned with each new ZLMS), it seems also overkill given that the scope associated with segments originated outside Java code is not very interesting - if users really care about lifetime of such segments they should override the scope with `MemorySegment::reinterpret`. This leads to some changes in the javadoc of other methods where I replaced `fresh scope that is always alive` with just `scope that is always alive`, to avoid suggesting that a new scope should be created each time.

Note to reviewers: I will also need a reviewer on the CSR. If you've reviewed that, please add yourself as reviewer (on the CSR). Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/16126#issuecomment-1760301526

From jvernee at openjdk.org  Thu Oct 12 20:30:17 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Oct 2023 20:30:17 GMT
Subject: RFR: 8317824: Beef up javadoc for base offset in var handles derived
 from layouts (mainline)
Message-ID: 

Port of: https://github.com/openjdk/panama-foreign/pull/901

Original PR body:

> This PR adds more javadoc to explain how base offsets in var handles obtained from layouts can be used.
> 
> First, a number of examples in the main `MemoryLayout` javadoc is rectified, as such examples did not use the additional base offset parameter (and were hence incorrect).
> 
> Second, the var handles part in the `MemorySegment` section on "accessing memory segment" has been rewritten to avoid duplication with the concepts exposed in `MemoryLayout`. Now we show how `MemorySegment::get` and `MemorySegment::getAtIndex` can be obtained using basic var handles and combinators. We mention that more complex var handles can be obtained using layout paths, but we now just reference the layout path section.
> 
> Last, I've added a new section on the `MemoryLayout` javadoc, with an example on how to deal with variable-length structs. This example showcases how var handles can be used in intricate situations, and combined with the new `scaleOffset` method.

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

Commit messages:
 - Beef up javadoc for base offset in var handles derived from layouts

Changes: https://git.openjdk.org/jdk/pull/16127/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16127&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317824
  Stats: 123 lines in 2 files changed: 78 ins; 17 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/16127.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16127/head:pull/16127

PR: https://git.openjdk.org/jdk/pull/16127

From vromero at openjdk.org  Thu Oct 12 20:45:23 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Oct 2023 20:45:23 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

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

> 364:             (selectorType.equals(int.class) && targetType.equals(Integer.class)))
> 365:             return true;
> 366:         else if (selectorType.equals(targetType) || (selectorType.equals(byte.class) && !targetType.equals(char.class)  ||

this code reminds me of some tricks we did to simplify similar code in the past, see `com.sun.tools.javac.code.TypeTag` and related:  `com.sun.tools.javac.code.TypeTag.NumericClasses` and method `com.sun.tools.javac.code.TypeTag::isSubRangeOf` and how it is used to determine if a numerical type is subtype of another numerical type. These tricks could be reused here, but up to you. I could also be done in a future refactoring.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357396699

From jvernee at openjdk.org  Thu Oct 12 20:47:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Oct 2023 20:47:24 GMT
Subject: RFR: 8317837: Leftover FFM implementation-only changes
Message-ID: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>

Port of miscellaneous leftover implementation-only changes from the panama-foreign repo:

These four related to improving the performance of the internal `strlen` implementation:

  - https://github.com/openjdk/panama-foreign/pull/862
  - https://github.com/openjdk/panama-foreign/pull/860
  - https://github.com/openjdk/panama-foreign/pull/858
  - https://github.com/openjdk/panama-foreign/pull/857
  
Adding new benchmarks:
  
  - https://github.com/openjdk/panama-foreign/pull/874
  - https://github.com/openjdk/panama-foreign/pull/870

Other misc. changes:

  - https://github.com/openjdk/panama-foreign/pull/885
  - https://github.com/openjdk/panama-foreign/pull/886
  - https://github.com/openjdk/panama-foreign/pull/864
  - https://github.com/openjdk/panama-foreign/pull/903
  - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a javadoc block in the implementation only)
  - https://github.com/openjdk/panama-foreign/pull/908
  - https://github.com/openjdk/panama-foreign/pull/910

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

Commit messages:
 - Do not run a lengthy test on zero machines
 - 8317137: Time out in TestStringEncoding
 - adjust misformatted copyright header
 - Fix arithmetic bug in SegmentAllocator
 - Improve exception messages and simplify LayoutPath
 - 8316196: Use hexadecimal form for address outputs in java.lang.foreign
 - Benchmark Java to/from C string conversions
 - Add AllocTest benchmark
 - Avoid using StandardCharset in Java code
 - Improve strlen performance
 - ... and 4 more: https://git.openjdk.org/jdk/compare/32ac72c3...b60dbff1

Changes: https://git.openjdk.org/jdk/pull/16128/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16128&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317837
  Stats: 1358 lines in 19 files changed: 1261 ins; 11 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/16128.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16128/head:pull/16128

PR: https://git.openjdk.org/jdk/pull/16128

From jvernee at openjdk.org  Thu Oct 12 20:48:19 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 12 Oct 2023 20:48:19 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline) [v2]
In-Reply-To: 
References: 
Message-ID: <8HuEL8yuapt_LhwmfP1GUeQ1WRTbaY72VshwGI02Aus=.24b982ee-ee97-4ee9-b669-01d9511133c4@github.com>

> Port of: https://github.com/openjdk/panama-foreign/pull/898
> 
> Original PR body:
> 
>> 
>> This patch addresses some issues with `MemorySegment.Scope::equals`. More specifically, when two segments are created from the same array/buffer, their underlying scope should be equal, but currently it is not, which is confusing.
>> 
>> This patch addesses that by adding a new subclass of `GlobalSession` (`HeapSession`) whose `equals`/`hashcode` methods are defined in terms of the heap reference it wraps. Note that the reference is deduped on construction - that is, we always try to find the "bottom" refrence that we should try to keep alive with the session, and we use that for comparisons (which avoid issues when comparing buffer slices and views).
>> 
>> As part of the changes, this patch also adds more javadoc on `MemorySegment.Scope` to document how equality works. And, this patch also makes all zero-length memory segments associate with the same "native" scope. This is a scope that is always alive, but is not the global scope (not to confuse with segments created by the global arena). While what the implementation does today is technically correct (a new fresh scope is returned with each new ZLMS), it seems also overkill given that the scope associated with segments originated outside Java code is not very interesting - if users really care about lifetime of such segments they should override the scope with `MemorySegment::reinterpret`. This leads to some changes in the javadoc of other methods where I replaced `fresh scope that is always alive` with just `scope that is always alive`, to avoid suggesting that a new scope should be created each time.

Jorn Vernee has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:

  8317050: Scope should reflect lifetime of underying resource
  
  Reviewed-by: jvernee

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16126/files
  - new: https://git.openjdk.org/jdk/pull/16126/files/ddc583d4..aba914fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16126&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16126&range=00-01

  Stats: 64 lines in 7 files changed: 7 ins; 15 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/16126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16126/head:pull/16126

PR: https://git.openjdk.org/jdk/pull/16126

From mcimadamore at openjdk.org  Thu Oct 12 20:52:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Oct 2023 20:52:16 GMT
Subject: RFR: 8317824: Beef up javadoc for base offset in var handles
 derived from layouts (mainline)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 17:58:12 GMT, Jorn Vernee  wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/901
> 
> Original PR body:
> 
>> This PR adds more javadoc to explain how base offsets in var handles obtained from layouts can be used.
>> 
>> First, a number of examples in the main `MemoryLayout` javadoc is rectified, as such examples did not use the additional base offset parameter (and were hence incorrect).
>> 
>> Second, the var handles part in the `MemorySegment` section on "accessing memory segment" has been rewritten to avoid duplication with the concepts exposed in `MemoryLayout`. Now we show how `MemorySegment::get` and `MemorySegment::getAtIndex` can be obtained using basic var handles and combinators. We mention that more complex var handles can be obtained using layout paths, but we now just reference the layout path section.
>> 
>> Last, I've added a new section on the `MemoryLayout` javadoc, with an example on how to deal with variable-length structs. This example showcases how var handles can be used in intricate situations, and combined with the new `scaleOffset` method.

Re-read the javadoc changes. Still looks good :-)

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16127#pullrequestreview-1675172960

From jlu at openjdk.org  Thu Oct 12 20:58:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Oct 2023 20:58:21 GMT
Subject: RFR: JDK-8317372: Refactor some NumberFormat tests to use JUnit
 [v3]
In-Reply-To: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
Message-ID: 

> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
> 
> During the switch to JUnit, the tests had the following updates (to improve readability)
> - separate the test data generation from the actual execution of the test
> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Swap grouping and decimal separator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16035/files
  - new: https://git.openjdk.org/jdk/pull/16035/files/22d7e1a6..7c62b652

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16035&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16035&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16035/head:pull/16035

PR: https://git.openjdk.org/jdk/pull/16035

From duke at openjdk.org  Thu Oct 12 21:49:00 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 12 Oct 2023 21:49:00 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v5]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: <0f6FgIrE9XOnCi43rn8bEqXMkeLCbqqeFakVuV2jPwQ=.d9da35b3-3ffc-4d15-9cbe-1cd9206a5b00@github.com>

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  refactor based on @cl4es 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/eec631cb..9dda9f70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=03-04

  Stats: 37 lines in 4 files changed: 0 ins; 35 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From naoto at openjdk.org  Thu Oct 12 21:54:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Oct 2023 21:54:14 GMT
Subject: RFR: JDK-8317372: Refactor some NumberFormat tests to use JUnit
 [v3]
In-Reply-To: 
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
 
Message-ID: 

On Thu, 12 Oct 2023 20:58:21 GMT, Justin Lu  wrote:

>> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
>> 
>> During the switch to JUnit, the tests had the following updates (to improve readability)
>> - separate the test data generation from the actual execution of the test
>> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swap grouping and decimal separator

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16035#pullrequestreview-1675263956

From vromero at openjdk.org  Thu Oct 12 22:40:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Oct 2023 22:40:22 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: <3CZrL-oopwafV6fQq-i-Jrbq-5eJ4bOzH52za4USkfs=.77c6db7c-6b0e-45b2-9c60-d66aba5d66a3@github.com>

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5055:

> 5053:         return (source.isPrimitive() && target.isPrimitive()) &&
> 5054:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||
> 5055:                         (source.hasTag(SHORT) && (target.hasTag(INT) || target.hasTag(LONG) || target.hasTag(FLOAT) || target.hasTag(DOUBLE)))||

this code can also be simplified as suggested for similar code in SwitchBootstraps, actually here you have access to the infra already in TypeTag and can leverage it.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2910:

> 2908:     }
> 2909: 
> 2910:     public void visitTypeTest(JCInstanceOf tree) {

would it make sense to document how the generated code should look like?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357407958
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357439742

From liach at openjdk.org  Fri Oct 13 01:21:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Oct 2023 01:21:05 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 24 Sep 2023 13:16:02 GMT, Chen Liang  wrote:

>> VarHandle implementations have many static fields and methods that can be pulled to the common superclass to avoid repeated initialization and code duplication.
>> 
>> In addition, the Unsafe-based Buffer field access are replaced by usage of public methods or JavaNioAccess.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Simplify non-Object array VH"
>   
>   This reverts commit 18d1be8b3b3aae1395d4096f5e2b95dbf078db0c.

Since the commit history of FFI API PR is lost, this pr is lost and cannot fix the conflicts by merging. Anticipate a force push to fix the state of this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/15854#issuecomment-1760621448

From duke at openjdk.org  Fri Oct 13 03:30:49 2023
From: duke at openjdk.org (xpbob)
Date: Fri, 13 Oct 2023 03:30:49 GMT
Subject: RFR: 8318058: Notify the jvm when the direct memory is oom
Message-ID: 

Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod

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

Commit messages:
 - 8318058: Notify the jvm when the direct memory is oom

Changes: https://git.openjdk.org/jdk/pull/16176/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16176&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318058
  Stats: 92 lines in 4 files changed: 87 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16176.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16176/head:pull/16176

PR: https://git.openjdk.org/jdk/pull/16176

From vromero at openjdk.org  Fri Oct 13 05:28:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Oct 2023 05:28:28 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: <-7dHm7aTGSEtcaNvl1RNNz2hgAbSVT6ljg-h9yRaMPc=.d1dafc1b-4828-497f-8c62-595060213a3f@github.com>

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

test/langtools/tools/javac/patterns/PrimitivePatternsComboTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2022, Oracle and/or its affiliates. All rights reserved.

nit: year should be 2023 only

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357760556

From stuefe at openjdk.org  Fri Oct 13 05:29:14 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 13 Oct 2023 05:29:14 GMT
Subject: RFR: 8318058: Notify the jvm when the direct memory is oom
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 03:23:04 GMT, xpbob  wrote:

> Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
> 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
> 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod

Undoubtedly useful, but there have been many discussions in the past about what does and does not constitute an OOM error, and IIRC, the stance of Oracle devs was "only if it is in java heap". Hence the missing OOM error when we cannot create threads, for instance.

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

PR Comment: https://git.openjdk.org/jdk/pull/16176#issuecomment-1760881555

From alanb at openjdk.org  Fri Oct 13 06:13:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Oct 2023 06:13:21 GMT
Subject: RFR: 8318058: Notify the jvm when the direct memory is oom
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 03:23:04 GMT, xpbob  wrote:

> Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
> 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
> 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod

JDK-8294052 has some of the previous discussion on this issue.

See also this thread where Man, Thomas, David and I discussed the topic:
https://mail.openjdk.org/pipermail/nio-dev/2022-September/012119.html

There were previous threads on the same topic, I can't find the links right now.

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

PR Comment: https://git.openjdk.org/jdk/pull/16176#issuecomment-1760950115

From mbaesken at openjdk.org  Fri Oct 13 06:53:34 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Oct 2023 06:53:34 GMT
Subject: RFR: JDK-8317959: Check return values of malloc in native
 java.base coding [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 12 Oct 2023 14:16:55 GMT, Matthias Baesken  wrote:

>> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doabort in check method in case no memory can be allocated

Hi Alan and Brian, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/16160#issuecomment-1760994212

From mbaesken at openjdk.org  Fri Oct 13 06:53:35 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Oct 2023 06:53:35 GMT
Subject: Integrated: JDK-8317959: Check return values of malloc in native
 java.base coding
In-Reply-To: 
References: 
Message-ID: 

On Thu, 12 Oct 2023 08:00:30 GMT, Matthias Baesken  wrote:

> There are a few remaining places in java.base where the return value NULL-check of malloc is missing. This should better be adjusted.

This pull request has now been integrated.

Changeset: ff0b397e
Author:    Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/ff0b397e135665fbc763bc4042b95c17f6c5367a
Stats:     29 lines in 4 files changed: 27 ins; 0 del; 2 mod

8317959: Check return values of malloc in native java.base coding

Reviewed-by: alanb, bpb

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

PR: https://git.openjdk.org/jdk/pull/16160

From mbaesken at openjdk.org  Fri Oct 13 06:56:22 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Oct 2023 06:56:22 GMT
Subject: RFR: JDK-8315026: ProcessHandle implementation listing processes
 on AIX should use getprocs64 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 12 Oct 2023 09:30:09 GMT, Joachim Kern  wrote:

>> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
>> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revise of the function comment and some other proposals

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16051#pullrequestreview-1675828762

From duke at openjdk.org  Fri Oct 13 07:14:30 2023
From: duke at openjdk.org (duke)
Date: Fri, 13 Oct 2023 07:14:30 GMT
Subject: Withdrawn: 8312424: 80% throughput decrease in
 Arrays.hashCode(Object[]) after JDK-8312164
In-Reply-To: 
References: 
Message-ID: <78wVwJ1TjsKeFbtloq4dZOx9KJRY0xLyI4fS9pteIO4=.9fce8bfa-af0c-42ee-8f80-bd19294e3bae@github.com>

On Thu, 20 Jul 2023 01:11:43 GMT, Glavo  wrote:

> The changes to `Arrays.hashCode(Object[])` in JDK-8312164 caused its performance  is reduced by about 80%.
> 
> This PR reverts this change.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/14944

From duke at openjdk.org  Fri Oct 13 07:41:02 2023
From: duke at openjdk.org (himichael)
Date: Fri, 13 Oct 2023 07:41:02 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - fix code style and formatting
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>  - change variable names of indexPivot* to pivotIndex*
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>  - Remove the unnecessary exception in single pivot partitioning fallback method
>  - Move functional interfaces close to the associated methods
>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>  - Refactor stub handling to use a generic function for all types
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
> 
> **Arrays.sort performance data using JMH benchmarks for arrays with random data**
> 
> Arrays.sort benchmark	Array Size	Baseline (us/op)	AVX512 Sort (us/op)	Speedup
> ArraysSort.doubleSort	10	0.034	0.035	1.0
> ArraysSort.doubleSort	25	0.116	0.089	1.3
> ArraysSort.doubleSort	50	0.282	0.291	1.0
> ArraysSort.doubleSort	75	0.474	0.358	1.3
> ArraysSort.doubleSort	100	0.654	0.623	1.0
> ArraysSort.doubleSort	1000	9.274	6.331	1.5
> ArraysSort.doubleSort	10000	323.339	71.228	**4.5**
> ArraysSort.doubleSort	100000	4471.871	1002.748	**4.5**
> ArraysSort.doubleSort	1000000	51660.742	12921.295	**4.0**
> ArraysSort.floatSort	10	0.045	0.046	1.0
> ArraysSort.floatSort	25	0.103	0.084	1.2
> ArraysSort.floatSort	50	0.285	0.33	0.9
> ArraysSort.floatSort	75	0.492	0.346	1.4
> ArraysSort.floatSort	100	0.597	0.326	1.8
> ArraysSort.floatSort	1000	9.811	5.294	1.9
> ArraysSort.floatSort	10000	323.955	50.547	**6.4**
> ArraysSort.floatSort	100000	4326.38	731.152	**5.9**
> ArraysSort.floatSort	1000000	52413.88	8409.193	**6.2**
> ArraysSort.intSort	10	0.033	0.033	1.0
> ArraysSort.intSort	25	0.086	0.051	1.7
> ArraysSort.intSort	50	0.236	0.151	1.6
> ArraysSort.intSort	75	0.416	0.332	1.3
> ArraysSort.intSort	100	0.63	0.521	1.2
> ArraysSort.intSort	1000	10.518	4.698	2.2
> ArraysSort.intSort	10000	309.659	42.518	**7.3**
> ArraysSort.intSort	100000	4130.917	573.956	**7.2**
> ArraysSort.intSort	1000000	49876.307	6712.812	**7.4**
> ArraysSort.longSort	10	0.036	0.037	1.0
> ArraysSort.longSort	25	0.094	0.08	1.2
> ArraysSort.longSort	50	0.218	0.227	1.0
> ArraysSort.longSort	75	0.466	0.402	1.2
> ArraysSort.longSort	100	0.76	0.58	1.3
> ArraysSort.longSort	1000	10.449	6.239	1.7
> ArraysSort.longSort	10000	307.074	70.284	**4.4**
> ArraysSort.longSort	100000	4135.651	1049.12	**3.9**
> ArraysSort.longSort	1000000	49559.152	12537.53	**4.0**
> This is the first in the series of PRs related to vectorized sorting. Future planned steps after the integration of this PR:
> 
> 1. Enabling AVX2 sort and partitioning for Linux ( based on Intel's x86-simd-sort [PR](https://github.com/intel/x86-simd-sort/pull/60)).
> 2. Enabling SIMD sort (both AVX512 and AVX2) for Short and Char arrays for length < 1750. (Arrays larger than 1750 already use countingSort which is faster than AVX512 sort.)
> 3. Adding Windows support for both AVX512 and AVX2 using assembly stubs.
> 4. Enabling SIMD sort (both AVX512 and AVX2) for MemorySegment.
> 
> ### Progress
> * [x]  Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> * [x]  Change must not contain extraneous whitespace
> * [x]  Commit message must refer to an issue
> 
> ### Issue
> * [JDK-8309130](https://bugs.openjdk.org/browse/JDK-8309130): x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) (**Enhancement** - P4)
> 
> ### Reviewers
> * [Jatin Bhateja](https://openjdk.org/census#jbhateja) (@jatin-bhateja - **Reviewer**) ?? Review applies to [e63a2aa0](https://git.openjdk.org/jdk/pull/14227/files/e63a2aa081275c3f1ed2ccc4315a60f304d18b34)
> * [Sandhya Viswanathan](https://openjdk.org/census#sviswanathan) (@sviswa7 - **Reviewer**) ?? Review applies to [9642d852](https://git.openjdk.org/jdk/pull/14227/files/9642d852cce5a9cf8270b850c124ef38fc158c6d)
> * [Paul Sandoz](https://openjdk.org/census#psandoz) (@PaulSandoz - **Reviewer**) ?? Review applies to [b04cb6c3](https://git.openjdk.org/jdk/pull/14227/files/b04cb6c3c41c7327f9dc67653e24b08693329e3e)
> * [Vladimir Kozlov](https://openjdk.org/census#kvn) (@vnkozlov - **Reviewer**)
> 
> ### Reviewing
> Using `git`
> Using Skara CLI tools
> Using diff file
> ### Webrev
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/14227#issuecomment-1568931001)

hello, I tested this feature in openjdk 22.19, but it didn't seem to work.   
my test code is as follows:   

public class JDKSort {
    public static void main(String[] args) {
        new JDKSort().sort();
    }

    public void sort() {
        // 100 million pieces of data
        int size = 100000000;
        int[] arr = new int[size];
        java.util.Random rand = new java.util.Random();
        for (int i = 0; i < size; ++i) {
            arr[i] = rand.nextInt();
        }

        long startTime = System.currentTimeMillis();
        java.util.Arrays.sort(arr);
        long elapseTime = System.currentTimeMillis() - startTime;
        System.out.println("elapse time -> " + elapseTime + " ms");
    }
}

test result:
- jdk8:   15079 ms
- jdk22:  11619 ms

this feature looks like it's merged into 22.19:   
[x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays)](https://bugs.openjdk.org/browse/JDK-8309130)   
but it doesn't seem to working, do I need to do anything?

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1761008818

From qamai at openjdk.org  Fri Oct 13 08:21:59 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 13 Oct 2023 08:21:59 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 
Message-ID: <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>

On Fri, 13 Oct 2023 07:02:18 GMT, himichael  wrote:

>> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
>> 
>>  - fix code style and formatting
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>>  - change variable names of indexPivot* to pivotIndex*
>>  - Update DualPivotQuicksort.java
>>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>>  - Remove the unnecessary exception in single pivot partitioning fallback method
>>  - Move functional interfaces close to the associated methods
>>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>>  - Refactor stub handling to use a generic function for all types
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86
>
>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data**
>> 
>> Arrays.sort benchmark	Array Size	Baseline (us/op)	AVX512 Sort (us/op)	Speedup
>> ArraysSort.doubleSort	10	0.034	0.035	1.0
>> ArraysSort.doubleSort	25	0.116	0.089	1.3
>> ArraysSort.doubleSort	50	0.282	0.291	1.0
>> ArraysSort.doubleSort	75	0.474	0.358	1.3
>> ArraysSort.doubleSort	100	0.654	0.623	1.0
>> ArraysSort.doubleSort	1000	9.274	6.331	1.5
>> ArraysSort.doubleSort	10000	323.339	71.228	**4.5**
>> ArraysSort.doubleSort	100000	4471.871	1002.748	**4.5**
>> ArraysSort.doubleSort	1000000	51660.742	12921.295	**4.0**
>> ArraysSort.floatSort	10	0.045	0.046	1.0
>> ArraysSort.floatSort	25	0.103	0.084	1.2
>> ArraysSort.floatSort	50	0.285	0.33	0.9
>> ArraysSort.floatSort	75	0.492	0.346	1.4
>> ArraysSort.floatSort	100	0.597	0.326	1.8
>> ArraysSort.floatSort	1000	9.811	5.294	1.9
>> ArraysSort.floatSort	10000	323.955	50.547	**6.4**
>> ArraysSort.floatSort	100000	4326.38	731.152	**5.9**
>> ArraysSort.floatSort	1000000	52413.88	8409.193	**6.2**
>> ArraysSort.intSort	10	0.033	0.033	1.0
>> ArraysSort.intSort	25	0.086	0.051	1.7
>> ArraysSort.intSort	50	0.236	0.151	1.6
>> ArraysSort.intSort	75	0.416	0.332	1.3
>> ArraysSort.intSort	100	0.63	0.521	1.2
>> ArraysSort.intSort	1000	10.518	4.698	2.2
>> ArraysSort.intSort	10000	309.659	42.518	**7.3**
>> ArraysSort.intSort	100000	4130.917	573.956	**7.2**
>> ArraysSort.intSort	1000000	49876.307	6712.812	**7.4**
>> ArraysSort.longSort	10	0.036	0.037	1.0
>> ArraysSort.longSort	25	0.094	0.08	1.2
>> ArraysSort.longSort	50	0.218	0.227	1.0
>> ArraysSort.longSort	75	0.466	0.402	1.2
>> ArraysSort.longSort	100	0.76	0.58	1.3
>> ArraysSort.longSort	1000	10.449	6.239	1.7
>> ArraysSort.longSort	10000	307.074	70.284	**4.4**
>> ArraysSort.longSort	100000	4135.651	1049.12	**3.9**
>> ArraysSort.longSort	1000000	49559.152	12537.53	**4.0**
>> This is the first in the series of PRs related to vectorized sorting. Future planned steps after the integration of this PR:
>> 
>> 1. Enabling AVX2 sort and partitioning for Linux ( based on Intel's x86-simd-sort [PR](https://github.com/intel/x86-simd-sort/pull/60)).
>> 2...

@himichael Please refer to [this question](https://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java) for how to correctly benchmark Java code.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1761104052

From jkern at openjdk.org  Fri Oct 13 08:33:32 2023
From: jkern at openjdk.org (Joachim Kern)
Date: Fri, 13 Oct 2023 08:33:32 GMT
Subject: Integrated: JDK-8315026: ProcessHandle implementation listing
 processes on AIX should use getprocs64
In-Reply-To: 
References: 
Message-ID: 

On Thu, 5 Oct 2023 10:02:05 GMT, Joachim Kern  wrote:

> We see rather often failures in java/lang/ProcessHandle/TreeTest.java on AIX in TreeTest.test5.
> The reason is: Previously the implementation based on the /proc file system lead to double pids in the child list; at least intermittent. Using the API getprocs64() instead I was able to eliminate those double pids (and increase the performance by a factor of 4). Otherwise we would have to add an algorithm to filter out the doubles after creating the raw list.

This pull request has now been integrated.

Changeset: 4d904204
Author:    Joachim Kern 
Committer: Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/4d9042043ecade75d50c25574a445e6b8ef43618
Stats:     139 lines in 2 files changed: 130 ins; 0 del; 9 mod

8315026: ProcessHandle implementation listing processes on AIX should use getprocs64

Reviewed-by: rriggs, stuefe, mbaesken

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

PR: https://git.openjdk.org/jdk/pull/16051

From coffeys at openjdk.org  Fri Oct 13 08:45:07 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 13 Oct 2023 08:45:07 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v3]
In-Reply-To: 
References: 
Message-ID: 

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  insert back lastmodified check. enhance testcase. more review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/847d0bd1..f930fac9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=01-02

  Stats: 98 lines in 2 files changed: 53 ins; 16 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From coffeys at openjdk.org  Fri Oct 13 08:48:18 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 13 Oct 2023 08:48:18 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 08:45:07 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   insert back lastmodified check. enhance testcase. more review comments

`lastModifiedTime()` was used in the native code and brought across when native code was removed in JDK-8145260

I thought we might be able to drop it for the case where we have a unique file key but that won't cover the case where an existing zip file is opened and modified. Re-introduced the lastModifiedTime checks as a result. We need to be able to detect such scenarios, otherwise new ZipFile constructs would continue to use a stale  mapping (if such Keys still existed)

I've updated the test case to junit format and beefed it up with some extra scenarios to cover the above.

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

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1761146357

From jvernee at openjdk.org  Fri Oct 13 09:00:49 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 09:00:49 GMT
Subject: RFR: 8318072: DonwcallLinker does not acquire/release segments in
 interpreter
Message-ID: 

Implement missing by-reference argument acquire/release functionality in DowncallLinker::invokeInterpBindings.

I've also simplified the related code a bit:
- `retIndexMap` was not used. I've removed it
- `BindingInterpreter.StoreFunc::store`'s type argument was not used. Removed
- UpcallLinker was redundantly collecting the move bindings for return values. Removed

I've added runs without specialization to the failing tests as well, so that we keep testing this.

Testing: `jdk_foreign` suite.

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

Commit messages:
 - minimize diff
 - implement missing acquire/release in interpreter

Changes: https://git.openjdk.org/jdk/pull/16177/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16177&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318072
  Stats: 64 lines in 6 files changed: 44 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16177/head:pull/16177

PR: https://git.openjdk.org/jdk/pull/16177

From rgiulietti at openjdk.org  Fri Oct 13 09:36:21 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Oct 2023 09:36:21 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis  wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 51:

> 49:      *
> 50:      * */
> 51:     public static boolean intToByteExact(int n)      {return n == (int)(byte)n;}

These ones seem more _conversions_ than _tests_.
To me, `intToByteExact(int)` looks more like a request to convert an `int` to a `byte`, rather than a check to see whether the argument lies in the `byte` range.
Pure methods returning `boolean` are often named like `isIntToByteExact(int)` or the like (`is*()`, `has*()`, etc.)

I know: choosing good, speaking, and evocative names is one of the hardest problem in computer science.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1358027977

From mdoerr at openjdk.org  Fri Oct 13 10:22:57 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Oct 2023 10:22:57 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function & Memory
 API
Message-ID: 

The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment.

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

Commit messages:
 - Change double alignment to 4 in tests.
 - 8317545: AIX PPC64: Implementation of Foreign Function & Memory API

Changes: https://git.openjdk.org/jdk/pull/16179/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16179&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317545
  Stats: 325 lines in 15 files changed: 234 ins; 78 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16179/head:pull/16179

PR: https://git.openjdk.org/jdk/pull/16179

From jvernee at openjdk.org  Fri Oct 13 10:28:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 10:28:46 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 10:12:24 GMT, Martin Doerr  wrote:

> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment. This PR is based on JDK22 version of the FFI.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java line 48:

> 46:     static {
> 47:         HashMap layouts = new HashMap<>();
> 48:         layouts.putAll(SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT));

You may also add an extra parameter for the double layout to SharedUtils::canonicalLayouts.

Also, what about `jdouble`? It seems to be defined to a native `double` on AIX as well? (see src/java.base/share/native/include/jni.h)

test/micro/org/openjdk/bench/java/lang/foreign/CLayouts.java line 68:

> 66:      * The layout for the {@code double} C type
> 67:      */
> 68:     public static final ValueLayout.OfDouble C_DOUBLE = ValueLayout.JAVA_DOUBLE.withByteAlignment(IS_AIX ? 4 : 8);

Would prefer if this used `Linker.canonicalLayouts`
Suggestion:

    public static final ValueLayout.OfDouble C_DOUBLE = (ValueLayout.OfDouble) LINKER.canonicalLayouts().get("double");

test/micro/org/openjdk/bench/java/lang/foreign/pointers/NativeType.java line 67:

> 65:         @Override
> 66:         public ValueLayout.OfDouble layout() {
> 67:             return ValueLayout.JAVA_DOUBLE.withByteAlignment(IS_AIX ? 4 : 8);

Same here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358079923
PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358076295
PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358076261

From duke at openjdk.org  Fri Oct 13 10:35:17 2023
From: duke at openjdk.org (himichael)
Date: Fri, 13 Oct 2023 10:35:17 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>
References: 
 
 
 <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>
Message-ID: 

On Fri, 13 Oct 2023 08:17:58 GMT, Quan Anh Mai  wrote:

> @himichael Please refer to [this question](https://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java) for how to correctly benchmark Java code.   

thanks for your reply, but I think this has nothing to do with benchmark.   
I sort a random array of int[], use: ```java.util.Arrays.sort()```    
in jdk 8, run command:  
```java JDKSort``` , the result display: 15079 ms   
   
in open jdk 22.19 , run command:   
```java --add-modules jdk.incubator.vector JDKSort```   
the result display:  11619 ms     
   
my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8.   
is there a problem with my configuration ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1761289130

From mcimadamore at openjdk.org  Fri Oct 13 12:02:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 12:02:49 GMT
Subject: RFR: 8318072: DonwcallLinker does not acquire/release segments in
 interpreter
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 08:00:07 GMT, Jorn Vernee  wrote:

> Implement missing by-reference argument acquire/release functionality in DowncallLinker::invokeInterpBindings.
> 
> I've also simplified the related code a bit:
> - `retIndexMap` was not used. I've removed it
> - `BindingInterpreter.StoreFunc::store`'s type argument was not used. Removed
> - UpcallLinker was redundantly collecting the move bindings for return values. Removed
> 
> I've added runs without specialization to the failing tests as well, so that we keep testing this.
> 
> Testing: `jdk_foreign` suite.

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16177#pullrequestreview-1676254470

From liach at openjdk.org  Fri Oct 13 12:14:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Oct 2023 12:14:53 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v7]
In-Reply-To: 
References: 
Message-ID: 

> VarHandle implementations have many static fields and methods that can be pulled to the common superclass to avoid repeated initialization and code duplication.
> 
> In addition, the Unsafe-based Buffer field access are replaced by usage of public methods or JavaNioAccess.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8316641: VarHandle template classes can share code in the base class

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

Changes: https://git.openjdk.org/jdk/pull/15854/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=06
  Stats: 201 lines in 7 files changed: 58 ins; 79 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/15854.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15854/head:pull/15854

PR: https://git.openjdk.org/jdk/pull/15854

From coffeys at openjdk.org  Fri Oct 13 12:18:41 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 13 Oct 2023 12:18:41 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v4]
In-Reply-To: 
References: 
Message-ID: 

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  minor test edits and comment updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/f930fac9..519014c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From duke at openjdk.org  Fri Oct 13 12:18:53 2023
From: duke at openjdk.org (Agnibho Hom Chowdhury)
Date: Fri, 13 Oct 2023 12:18:53 GMT
Subject: RFR: JDK-8249832:
 java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id [v3]
In-Reply-To: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
References: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
Message-ID: 

> Please review this PR as a fix of [JDK-8249832](https://bugs.openjdk.org/browse/JDK-8249832). I have added the bug with after @ignore annotation.

Agnibho Hom Chowdhury has updated the pull request incrementally with one additional commit since the last revision:

  reverted copyright year update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16073/files
  - new: https://git.openjdk.org/jdk/pull/16073/files/a5b9a2fc..da9e5edc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16073&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16073&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16073/head:pull/16073

PR: https://git.openjdk.org/jdk/pull/16073

From mdoerr at openjdk.org  Fri Oct 13 12:19:06 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Oct 2023 12:19:06 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
Message-ID: 

> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment. This PR is based on JDK22 version of the FFI.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Improve micro benchmarks and a comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16179/files
  - new: https://git.openjdk.org/jdk/pull/16179/files/3e4169a0..42d38e06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16179&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16179&range=00-01

  Stats: 19 lines in 3 files changed: 3 ins; 5 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16179/head:pull/16179

PR: https://git.openjdk.org/jdk/pull/16179

From mchhipa at openjdk.org  Fri Oct 13 12:19:04 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 13 Oct 2023 12:19:04 GMT
Subject: RFR: JDK-8249832:
 java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id [v2]
In-Reply-To: 
References: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
 
Message-ID: 

On Thu, 12 Oct 2023 14:18:16 GMT, Agnibho Hom Chowdhury  wrote:

>> Please review this PR as a fix of [JDK-8249832](https://bugs.openjdk.org/browse/JDK-8249832). I have added the bug with after @ignore annotation.
>
> Agnibho Hom Chowdhury has updated the pull request incrementally with one additional commit since the last revision:
> 
>   upadted copyright year

Looks Good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/16073#issuecomment-1761300374

From jvernee at openjdk.org  Fri Oct 13 12:18:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 12:18:59 GMT
Subject: RFR: 8317837: Leftover FFM implementation-only changes [v2]
In-Reply-To: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
References: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
Message-ID: 

> Port of miscellaneous leftover implementation-only changes from the panama-foreign repo:
> 
> These four related to improving the performance of the internal `strlen` implementation:
> 
>   - https://github.com/openjdk/panama-foreign/pull/862
>   - https://github.com/openjdk/panama-foreign/pull/860
>   - https://github.com/openjdk/panama-foreign/pull/858
>   - https://github.com/openjdk/panama-foreign/pull/857
>   
> Adding new benchmarks:
>   
>   - https://github.com/openjdk/panama-foreign/pull/874
>   - https://github.com/openjdk/panama-foreign/pull/870
> 
> Other misc. changes:
> 
>   - https://github.com/openjdk/panama-foreign/pull/885
>   - https://github.com/openjdk/panama-foreign/pull/886
>   - https://github.com/openjdk/panama-foreign/pull/864
>   - https://github.com/openjdk/panama-foreign/pull/903
>   - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a javadoc block in the implementation only)
>   - https://github.com/openjdk/panama-foreign/pull/908
>   - https://github.com/openjdk/panama-foreign/pull/910
>   
> Testing: `jdk_foreign`

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  8315041: Optimize Java to C string conversion by avoiding double copy
  
  Reviewed-by: pminborg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16128/files
  - new: https://git.openjdk.org/jdk/pull/16128/files/b60dbff1..cfc31040

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16128&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16128&range=00-01

  Stats: 87 lines in 5 files changed: 72 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/16128.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16128/head:pull/16128

PR: https://git.openjdk.org/jdk/pull/16128

From mcimadamore at openjdk.org  Fri Oct 13 12:19:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 12:19:04 GMT
Subject: RFR: 8317837: Leftover FFM implementation-only changes [v2]
In-Reply-To: 
References: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 11:32:09 GMT, Jorn Vernee  wrote:

>> Port of miscellaneous leftover implementation-only changes from the panama-foreign repo:
>> 
>> These four related to improving the performance of the internal `strlen` implementation:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/862
>>   - https://github.com/openjdk/panama-foreign/pull/860
>>   - https://github.com/openjdk/panama-foreign/pull/858
>>   - https://github.com/openjdk/panama-foreign/pull/857
>>   
>> Adding new benchmarks:
>>   
>>   - https://github.com/openjdk/panama-foreign/pull/874
>>   - https://github.com/openjdk/panama-foreign/pull/870
>> 
>> Other misc. changes:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/885
>>   - https://github.com/openjdk/panama-foreign/pull/886
>>   - https://github.com/openjdk/panama-foreign/pull/864
>>   - https://github.com/openjdk/panama-foreign/pull/903
>>   - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a javadoc block in the implementation only)
>>   - https://github.com/openjdk/panama-foreign/pull/908
>>   - https://github.com/openjdk/panama-foreign/pull/910
>>   
>> Testing: `jdk_foreign`
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315041: Optimize Java to C string conversion by avoiding double copy
>   
>   Reviewed-by: pminborg

Looks good.
It seems like this PR is missing some string optimizations:
https://git.openjdk.org/panama-foreign/pull/875

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

PR Review: https://git.openjdk.org/jdk/pull/16128#pullrequestreview-1676251850

From jvernee at openjdk.org  Fri Oct 13 12:19:12 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 12:19:12 GMT
Subject: RFR: 8317837: Leftover FFM implementation-only changes
In-Reply-To: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
References: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
Message-ID: 

On Tue, 10 Oct 2023 21:41:01 GMT, Jorn Vernee  wrote:

> Port of miscellaneous leftover implementation-only changes from the panama-foreign repo:
> 
> These four related to improving the performance of the internal `strlen` implementation:
> 
>   - https://github.com/openjdk/panama-foreign/pull/862
>   - https://github.com/openjdk/panama-foreign/pull/860
>   - https://github.com/openjdk/panama-foreign/pull/858
>   - https://github.com/openjdk/panama-foreign/pull/857
>   
> Adding new benchmarks:
>   
>   - https://github.com/openjdk/panama-foreign/pull/874
>   - https://github.com/openjdk/panama-foreign/pull/870
> 
> Other misc. changes:
> 
>   - https://github.com/openjdk/panama-foreign/pull/885
>   - https://github.com/openjdk/panama-foreign/pull/886
>   - https://github.com/openjdk/panama-foreign/pull/864
>   - https://github.com/openjdk/panama-foreign/pull/903
>   - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a javadoc block in the implementation only)
>   - https://github.com/openjdk/panama-foreign/pull/908
>   - https://github.com/openjdk/panama-foreign/pull/910
>   
> Testing: `jdk_foreign`

Thanks for the review. I've added the missing patch now

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

PR Comment: https://git.openjdk.org/jdk/pull/16128#issuecomment-1761359037

From mchhipa at openjdk.org  Fri Oct 13 12:21:28 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 13 Oct 2023 12:21:28 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v9]
In-Reply-To: 
References: 
Message-ID: 

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Tests with base64 input are removed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/a01dc7e2..5326282f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=07-08

  Stats: 232 lines in 8 files changed: 0 ins; 228 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From dl at openjdk.org  Fri Oct 13 12:21:16 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 13 Oct 2023 12:21:16 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v50]
In-Reply-To: 
References: 
Message-ID: 

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

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

 - Merge branch 'openjdk:master' into JDK-8288899
 - More cleanup
 - Merge branch 'openjdk:master' into JDK-8288899
 - better window encoding
 - Merge branch 'openjdk:master' into JDK-8288899
 - cleanup
 - Merge branch 'openjdk:master' into JDK-8288899
 - refactor termination
 - Undo stray edit
 - Streamline push; add redundant interrupts
 - ... and 88 more: https://git.openjdk.org/jdk/compare/914d79dc...005ea626

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/45585dc3..005ea626

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=48-49

  Stats: 9187 lines in 430 files changed: 4580 ins; 2866 del; 1741 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From mdoerr at openjdk.org  Fri Oct 13 12:26:48 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Oct 2023 12:26:48 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 10:21:06 GMT, Jorn Vernee  wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve micro benchmarks and a comment.
>
> test/micro/org/openjdk/bench/java/lang/foreign/CLayouts.java line 68:
> 
>> 66:      * The layout for the {@code double} C type
>> 67:      */
>> 68:     public static final ValueLayout.OfDouble C_DOUBLE = ValueLayout.JAVA_DOUBLE.withByteAlignment(IS_AIX ? 4 : 8);
> 
> Would prefer if this used `Linker.canonicalLayouts`
> Suggestion:
> 
>     public static final ValueLayout.OfDouble C_DOUBLE = (ValueLayout.OfDouble) LINKER.canonicalLayouts().get("double");

I've improved the micro benchmarks with 3rd commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358190616

From mdoerr at openjdk.org  Fri Oct 13 12:41:01 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Oct 2023 12:41:01 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
 
Message-ID: <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>

On Fri, 13 Oct 2023 10:24:58 GMT, Jorn Vernee  wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve micro benchmarks and a comment.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java line 48:
> 
>> 46:     static {
>> 47:         HashMap layouts = new HashMap<>();
>> 48:         layouts.putAll(SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT));
> 
> You may also add an extra parameter for the double layout to SharedUtils::canonicalLayouts.
> 
> Also, what about `jdouble`? It seems to be defined to a native `double` on AIX as well? (see src/java.base/share/native/include/jni.h)

Not sure how `jdouble` would be used. JNI doesn't support C structures and the double alignment is only an issue in structures. Do we support embedding `jdouble` in structures? I guess changing it would probably be better?
Note that we will need something which maps to the 8-Byte aligned `double`. Otherwise we get an Exception when passing a `JAVA_DOUBLE` as normal argument:

IllegalArgumentException: Unsupported layout: D8
        at java.base/jdk.internal.foreign.abi.AbstractLinker.checkSupported(AbstractLinker.java:244)
        at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayoutRecursive(AbstractLinker.java:185)
        at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayout(AbstractLinker.java:179)
        at java.base/java.lang.Iterable.forEach(Iterable.java:75)
        at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayouts(AbstractLinker.java:171)
        at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle0(AbstractLinker.java:98)
        at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle(AbstractLinker.java:85)
        at TestDowncall.(TestDowncall.java:127)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358201012

From redestad at openjdk.org  Fri Oct 13 12:49:44 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 13 Oct 2023 12:49:44 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v5]
In-Reply-To: <0f6FgIrE9XOnCi43rn8bEqXMkeLCbqqeFakVuV2jPwQ=.d9da35b3-3ffc-4d15-9cbe-1cd9206a5b00@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 <0f6FgIrE9XOnCi43rn8bEqXMkeLCbqqeFakVuV2jPwQ=.d9da35b3-3ffc-4d15-9cbe-1cd9206a5b00@github.com>
Message-ID: 

On Thu, 12 Oct 2023 21:49:00 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor based on @cl4es 's review

Thanks for simplifying. It seems that even regular `StringBuilder`-based concat gives numbers that are competitive with the baseline this way. I'll file an RFE to examine if we can enable ISC for this.

I've requested another reviewer for this, since I don't have the sufficient floating point domain expertise to review these changes alone.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16006#pullrequestreview-1676418305

From jvernee at openjdk.org  Fri Oct 13 13:04:47 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 13:04:47 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
Message-ID: 

On Fri, 13 Oct 2023 12:34:53 GMT, Martin Doerr  wrote:

> I guess changing it would probably be better?

Yeah, I think so.

> Note that we will need something which maps to the 8-Byte aligned double. Otherwise we get an Exception when passing a JAVA_DOUBLE as normal argument.

Okay, so it sounds like Java double on AIX is still 8-byte aligned, but the native double is 4-byte aligned?

In that case, I'd say that passing `JAVA_DOUBLE` as an argument resulting in an exception, is expected behavior. Using `JAVA_DOUBLE` to link native functions works more or less by coincidence, since it has the same layout as the native `double`, on all other platforms. The AIX issue with double is not dissimilar to using JAVA_LONG to link against a function taking a native `long` on Windows, in which case the size of the type doesn't match.

The philosophy here is: a client is responsible for passing the right FunctionDescriptor/layouts, that matches the native function declaration. On AIX, JAVA_DOUBLE is just never the right layout, and the linker detects this and throws an exception.

I understand that some tests might be lazy and use JAVA_DOUBLE to link functions. It is fine to update those tests, e.g. to use C_DOUBLE defined in NativeTestHelper.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358238373

From mdoerr at openjdk.org  Fri Oct 13 13:43:01 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Oct 2023 13:43:01 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
Message-ID: 

On Fri, 13 Oct 2023 13:37:10 GMT, Jorn Vernee  wrote:

>>> I guess changing it would probably be better?
>> 
>> Yeah, I think so.
>> 
>>> Note that we will need something which maps to the 8-Byte aligned double. Otherwise we get an Exception when passing a JAVA_DOUBLE as normal argument.
>> 
>> Okay, so it sounds like Java double on AIX is still 8-byte aligned, but the native double is 4-byte aligned?
>> 
>> In that case, I'd say that passing `JAVA_DOUBLE` as an argument resulting in an exception, is expected behavior. Using `JAVA_DOUBLE` to link native functions works more or less by coincidence, since it has the same layout as the native `double`, on all other platforms. The AIX issue with double is not dissimilar to using JAVA_LONG to link against a function taking a native `long` on Windows, in which case the size of the type doesn't match.
>> 
>> The philosophy here is: a client is responsible for passing the right FunctionDescriptor/layouts, that matches the native function declaration. On AIX, JAVA_DOUBLE is just never the right layout, and the linker detects this and throws an exception.
>> 
>> I understand that some of the existing tests might be lazy and use JAVA_DOUBLE to link functions. It is fine to update those tests, e.g. to use C_DOUBLE defined in NativeTestHelper.
>
> Just to clarify, is the ABI equal to what is described in this table: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes ?
> 
> This shows `double` having 8-byte alignment, but being 4-byte aligned when not the first member of an aggregate.

> Okay, so it sounds like Java double on AIX is still 8-byte aligned, but the native double is 4-byte aligned?

Correct within structures. I believe they are always 8-byte aligned except in structures which are packed more densely.

> In that case, I'd say that passing `JAVA_DOUBLE` as an argument resulting in an exception, is expected behavior. 

Hmm... Should we disallow to pass 8-byte aligned double values? Fixing the tests is a good thing. But, I have a different concern: I guess many developers may use them without testing on AIX. This would cause problems which we could avoid by supporting 8-byte aligned doubles in addition.

What about adding

layouts.put("jdouble", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
layouts.put("aligneddouble", ValueLayout.JAVA_DOUBLE); // allowed for usage outside of structures

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358281371

From jvernee at openjdk.org  Fri Oct 13 13:43:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 13:43:01 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 13:02:24 GMT, Jorn Vernee  wrote:

>> Not sure how `jdouble` would be used. JNI doesn't support C structures and the double alignment is only an issue in structures. Do we support embedding `jdouble` in structures? I guess changing it would probably be better?
>> Note that we will need something which maps to the 8-Byte aligned `double`. Otherwise we get an Exception when passing a `JAVA_DOUBLE` as normal argument:
>> 
>> IllegalArgumentException: Unsupported layout: D8
>>         at java.base/jdk.internal.foreign.abi.AbstractLinker.checkSupported(AbstractLinker.java:244)
>>         at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayoutRecursive(AbstractLinker.java:185)
>>         at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayout(AbstractLinker.java:179)
>>         at java.base/java.lang.Iterable.forEach(Iterable.java:75)
>>         at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayouts(AbstractLinker.java:171)
>>         at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle0(AbstractLinker.java:98)
>>         at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle(AbstractLinker.java:85)
>>         at TestDowncall.(TestDowncall.java:127)
>
>> I guess changing it would probably be better?
> 
> Yeah, I think so.
> 
>> Note that we will need something which maps to the 8-Byte aligned double. Otherwise we get an Exception when passing a JAVA_DOUBLE as normal argument.
> 
> Okay, so it sounds like Java double on AIX is still 8-byte aligned, but the native double is 4-byte aligned?
> 
> In that case, I'd say that passing `JAVA_DOUBLE` as an argument resulting in an exception, is expected behavior. Using `JAVA_DOUBLE` to link native functions works more or less by coincidence, since it has the same layout as the native `double`, on all other platforms. The AIX issue with double is not dissimilar to using JAVA_LONG to link against a function taking a native `long` on Windows, in which case the size of the type doesn't match.
> 
> The philosophy here is: a client is responsible for passing the right FunctionDescriptor/layouts, that matches the native function declaration. On AIX, JAVA_DOUBLE is just never the right layout, and the linker detects this and throws an exception.
> 
> I understand that some of the existing tests might be lazy and use JAVA_DOUBLE to link functions. It is fine to update those tests, e.g. to use C_DOUBLE defined in NativeTestHelper.

Just to clarify, is the ABI equal to what is described in this table: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes ?

This shows `double` having 8-byte alignment, but being 4-byte aligned when not the first member of an aggregate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358279022

From jvernee at openjdk.org  Fri Oct 13 13:50:02 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 13:50:02 GMT
Subject: Withdrawn: 8317819: Scope should reflect lifetime of underying
 resource (mainline)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 17:17:00 GMT, Jorn Vernee  wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/898
> 
> Original PR body:
> 
>> 
>> This patch addresses some issues with `MemorySegment.Scope::equals`. More specifically, when two segments are created from the same array/buffer, their underlying scope should be equal, but currently it is not, which is confusing.
>> 
>> This patch addesses that by adding a new subclass of `GlobalSession` (`HeapSession`) whose `equals`/`hashcode` methods are defined in terms of the heap reference it wraps. Note that the reference is deduped on construction - that is, we always try to find the "bottom" refrence that we should try to keep alive with the session, and we use that for comparisons (which avoid issues when comparing buffer slices and views).
>> 
>> As part of the changes, this patch also adds more javadoc on `MemorySegment.Scope` to document how equality works. And, this patch also makes all zero-length memory segments associate with the same "native" scope. This is a scope that is always alive, but is not the global scope (not to confuse with segments created by the global arena). While what the implementation does today is technically correct (a new fresh scope is returned with each new ZLMS), it seems also overkill given that the scope associated with segments originated outside Java code is not very interesting - if users really care about lifetime of such segments they should override the scope with `MemorySegment::reinterpret`. This leads to some changes in the javadoc of other methods where I replaced `fresh scope that is always alive` with just `scope that is always alive`, to avoid suggesting that a new scope should be created each time.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/16126

From s.h.w.vanhulst at gmail.com  Fri Oct 13 14:00:00 2023
From: s.h.w.vanhulst at gmail.com (Stephan van Hulst)
Date: Fri, 13 Oct 2023 16:00:00 +0200
Subject: 8176407: (scanner) Scanner delimits incorrectly when delimiter spans
 a buffer boundary
Message-ID: 

Hello all, I'm new to the mailing list.

This week I've run into an issue that was already reported here:
https://bugs.openjdk.org/browse/JDK-8176407

JDK-8176407 is actually a clone of JDK-8072582, which was fixed but
then partially reverted because according to Xueming Shen, it
"triggered the regression reported in JDK-8159545".

The original fix:
https://github.com/openjdk/jdk/commit/5aad7937b7fd3715b173ab1b0f7d093c1735dfc9
The reversion: https://github.com/openjdk/jdk/commit/e922fb0afba26216109aa81f42420b6ddd5c1602

I would like to contribute a fix to the problem, but I can't find or
access JDK-8159545, so I don't know what regression was triggered by
the original fix.

Kind regards,

Stephan

From mdoerr at openjdk.org  Fri Oct 13 14:31:47 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Oct 2023 14:31:47 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
 
Message-ID: <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>

On Fri, 13 Oct 2023 13:39:11 GMT, Martin Doerr  wrote:

>> Just to clarify, is the ABI equal to what is described in this table: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes ?
>> 
>> This shows `double` having 8-byte alignment, but being 4-byte aligned when not the first member of an aggregate.
>
>> Okay, so it sounds like Java double on AIX is still 8-byte aligned, but the native double is 4-byte aligned?
> 
> Correct within structures. I believe they are always 8-byte aligned except in structures which are packed more densely.
> 
>> In that case, I'd say that passing `JAVA_DOUBLE` as an argument resulting in an exception, is expected behavior. 
> 
> Hmm... Should we disallow to pass 8-byte aligned double values? Fixing the tests is a good thing. But, I have a different concern: I guess many developers may use them without testing on AIX. This would cause problems which we could avoid by supporting 8-byte aligned doubles in addition.
> 
> What about adding
> 
> layouts.put("jdouble", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
> layouts.put("aligneddouble", ValueLayout.JAVA_DOUBLE); // allowed for usage outside of structures
> 
> ?

> Just to clarify, is the ABI equal to what is described in this table: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes ?
> 
> This shows `double` having 8-byte alignment, but being 4-byte aligned when not the first member of an aggregate.

Interesting! This matches my understanding. I can see that doubles are 4-byte aligned within structures. The 8-byte alignment of the first member is already established by the allocation alignment.

I have only read the ABI documentation for linux. IBM will have to cover AIX specific details if there are more questions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358313306

From jvernee at openjdk.org  Fri Oct 13 14:31:48 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 14:31:48 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
 
 <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>
Message-ID: 

On Fri, 13 Oct 2023 14:03:34 GMT, Martin Doerr  wrote:

>>> Okay, so it sounds like Java double on AIX is still 8-byte aligned, but the native double is 4-byte aligned?
>> 
>> Correct within structures. I believe they are always 8-byte aligned except in structures which are packed more densely.
>> 
>>> In that case, I'd say that passing `JAVA_DOUBLE` as an argument resulting in an exception, is expected behavior. 
>> 
>> Hmm... Should we disallow to pass 8-byte aligned double values? Fixing the tests is a good thing. But, I have a different concern: I guess many developers may use them without testing on AIX. This would cause problems which we could avoid by supporting 8-byte aligned doubles in addition.
>> 
>> What about adding
>> 
>> layouts.put("jdouble", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
>> layouts.put("aligneddouble", ValueLayout.JAVA_DOUBLE); // allowed for usage outside of structures
>> 
>> ?
>
>> Just to clarify, is the ABI equal to what is described in this table: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes ?
>> 
>> This shows `double` having 8-byte alignment, but being 4-byte aligned when not the first member of an aggregate.
> 
> Interesting! This matches my understanding. I can see that doubles are 4-byte aligned within structures. The 8-byte alignment of the first member is already established by the allocation alignment.
> 
> I have only read the ABI documentation for linux. IBM will have to cover AIX specific details if there are more questions.

Discussed this a bit with Maurizio. There are a few things to consider:

- `cannonicalLayouts` allows for just a single mapping from type name to layout. I think `double` should map to the 8-byte aligned layout. (the same alignment you get from `_Alignof(double)` in C).
- We have to relax the checking done by the linker on AIX. Maybe change `AbstractLinker::checkLayoutRecursive` call some `checkStructMemberLayout` method, that by default just calls `checkLayoutRecursive`, but which the AIX linker can override to implement it's special rules for doubles.
- We need a small spec update to allow for struct field layouts that are not canonical layouts. I'll take a stab at that, and then get back to you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358344403

From mcimadamore at openjdk.org  Fri Oct 13 14:32:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 14:32:15 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline)
Message-ID: 

This PR is based on a port of: openjdk/panama-foreign#898

Some additional changes are contained in this PR:

* instead of using a different "always alive" scope for zero-length memory segments, we now use the global scope
* the javadoc for `MemorySegment::ofArray`, `MemorySegment::ofBuffer` and `SymbolLookup::loaderLookup` is tweaked to say that the scope associated to the returned segments is an automatic scope
* the javadoc for `MemorySegment.Scope` defines the concepts of global and automatic scope, which are then referenced in the `Arena` javadoc.

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

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/16183/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16183&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317819
  Stats: 147 lines in 11 files changed: 83 ins; 15 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/16183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16183/head:pull/16183

PR: https://git.openjdk.org/jdk/pull/16183

From mdoerr at openjdk.org  Fri Oct 13 14:51:29 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Oct 2023 14:51:29 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
 
 <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 14:28:58 GMT, Jorn Vernee  wrote:

>>> Just to clarify, is the ABI equal to what is described in this table: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes ?
>>> 
>>> This shows `double` having 8-byte alignment, but being 4-byte aligned when not the first member of an aggregate.
>> 
>> Interesting! This matches my understanding. I can see that doubles are 4-byte aligned within structures. The 8-byte alignment of the first member is already established by the allocation alignment.
>> 
>> I have only read the ABI documentation for linux. IBM will have to cover AIX specific details if there are more questions.
>
> Discussed this a bit with Maurizio. There are a few things to consider:
> 
> - `cannonicalLayouts` allows for just a single mapping from type name to layout. I think `double` should map to the 8-byte aligned layout. (the same alignment you get from `_Alignof(double)` in C).
> - We have to relax the checking done by the linker on AIX. Maybe change `AbstractLinker::checkLayoutRecursive` call some `checkStructMemberLayout` method, that by default just calls `checkLayoutRecursive`, but which the AIX linker can override to implement it's special rules for doubles.
> - We need a small spec update to allow for struct field layouts that are not canonical layouts. I'll take a stab at that, and then get back to you.

Thanks for your outstanding support! I'm awaiting feedback from IBM and a solution for the subtask https://bugs.openjdk.org/browse/JDK-8317799. There shouldn't be much work to be done after that, I guess.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1358368099

From mcimadamore at openjdk.org  Fri Oct 13 15:04:59 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 15:04:59 GMT
Subject: RFR: 8317837: Leftover FFM implementation-only changes [v2]
In-Reply-To: 
References: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 12:18:59 GMT, Jorn Vernee  wrote:

>> Port of miscellaneous leftover implementation-only changes from the panama-foreign repo:
>> 
>> These four related to improving the performance of the internal `strlen` implementation:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/862
>>   - https://github.com/openjdk/panama-foreign/pull/860
>>   - https://github.com/openjdk/panama-foreign/pull/858
>>   - https://github.com/openjdk/panama-foreign/pull/857
>>   
>> Adding new benchmarks:
>>   
>>   - https://github.com/openjdk/panama-foreign/pull/874
>>   - https://github.com/openjdk/panama-foreign/pull/870
>> 
>> Other misc. changes:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/885
>>   - https://github.com/openjdk/panama-foreign/pull/886
>>   - https://github.com/openjdk/panama-foreign/pull/864
>>   - https://github.com/openjdk/panama-foreign/pull/903
>>   - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a javadoc block in the implementation only)
>>   - https://github.com/openjdk/panama-foreign/pull/908
>>   - https://github.com/openjdk/panama-foreign/pull/910
>>   
>> Testing: `jdk_foreign`
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315041: Optimize Java to C string conversion by avoiding double copy
>   
>   Reviewed-by: pminborg

This seems to have been missed too? https://github.com/openjdk/panama-foreign/pull/897

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

PR Comment: https://git.openjdk.org/jdk/pull/16128#issuecomment-1761668250

From mcimadamore at openjdk.org  Fri Oct 13 15:14:34 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 15:14:34 GMT
Subject: RFR: 8317837: Leftover FFM implementation-only changes [v2]
In-Reply-To: 
References: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 12:18:59 GMT, Jorn Vernee  wrote:

>> Port of miscellaneous leftover implementation-only changes from the panama-foreign repo:
>> 
>> These four related to improving the performance of the internal `strlen` implementation:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/862
>>   - https://github.com/openjdk/panama-foreign/pull/860
>>   - https://github.com/openjdk/panama-foreign/pull/858
>>   - https://github.com/openjdk/panama-foreign/pull/857
>>   
>> Adding new benchmarks:
>>   
>>   - https://github.com/openjdk/panama-foreign/pull/874
>>   - https://github.com/openjdk/panama-foreign/pull/870
>> 
>> Other misc. changes:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/885
>>   - https://github.com/openjdk/panama-foreign/pull/886
>>   - https://github.com/openjdk/panama-foreign/pull/864
>>   - https://github.com/openjdk/panama-foreign/pull/903
>>   - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a javadoc block in the implementation only)
>>   - https://github.com/openjdk/panama-foreign/pull/908
>>   - https://github.com/openjdk/panama-foreign/pull/910
>>   
>> Testing: `jdk_foreign`
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315041: Optimize Java to C string conversion by avoiding double copy
>   
>   Reviewed-by: pminborg

> This seems to have been missed too? [openjdk/panama-foreign#897](https://github.com/openjdk/panama-foreign/pull/897)

I also don't see https://git.openjdk.org/panama-foreign/pull/894

Perhaps you are planning a different PR for "style" only changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/16128#issuecomment-1761681674

From mcimadamore at openjdk.org  Fri Oct 13 15:39:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 15:39:06 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline) [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR is based on a port of: openjdk/panama-foreign#898
> 
> Some additional changes are contained in this PR:
> 
> * instead of using a different "always alive" scope for zero-length memory segments, we now use the global scope
> * the javadoc for `MemorySegment::ofArray`, `MemorySegment::ofBuffer` and `SymbolLookup::loaderLookup` is tweaked to say that the scope associated to the returned segments is an automatic scope
> * the javadoc for `MemorySegment.Scope` defines the concepts of global and automatic scope, which are then referenced in the `Arena` javadoc.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16183/files
  - new: https://git.openjdk.org/jdk/pull/16183/files/c4631037..a9de77cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16183&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16183&range=00-01

  Stats: 122 lines in 1 file changed: 122 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16183/head:pull/16183

PR: https://git.openjdk.org/jdk/pull/16183

From igavrilin at openjdk.org  Fri Oct 13 15:45:27 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Fri, 13 Oct 2023 15:45:27 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D intrinsics
Message-ID: 

Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.

Tests:
Performance tests on t-head board:
With intrinsics:

Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms

Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):

Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms

Regression tests: tier1, hotspot:tier2 on risc-v board.

Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:

diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
index 6cd1353907e..0bee25366bf 100644
--- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
+++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
@@ -143,12 +143,12 @@ public double  ceilDouble() {
 
     @Benchmark
     public double  copySignDouble() {
-        return  Math.copySign(double81, doubleNegative12);
+        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
     }
 
     @Benchmark
     public float  copySignFloat() {
-        return  Math.copySign(floatNegative99, float1);
+        return  Math.copySign(floatNegative99, float1) + Math.copySign(eFloat, float1) + Math.copySign(eFloat, floatNegative99);
     }
 
     @Benchmark
@@ -472,12 +472,12 @@ public float  scalbFloatInt() {
 
     @Benchmark
     public double  sigNumDouble() {
-        return  Math.signum(double4Dot1);
+        return  Math.signum(double4Dot1) + Math.signum(doubleNegative12) + Math.signum(double81);
     }
 
     @Benchmark
     public double  signumFloat() {
-        return  Math.signum(floatNegative99);
+        return  Math.signum(floatNegative99) + Math.signum(float2) + Math.signum(float7);
     }
 
     @Benchmark

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

Commit messages:
 - Implement copySign and signum intrinsics

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

PR: https://git.openjdk.org/jdk/pull/16186

From rriggs at openjdk.org  Fri Oct 13 15:48:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 13 Oct 2023 15:48:44 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 12:21:28 GMT, Mahendra Chhipa  wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tests with base64 input are removed.

test/jdk/javax/xml/jaxp/datatype/8033980/GregorianCalAndDurSerDataUtil.java line 118:

> 116:             fmt.format(" (byte) 0x%x,", bytes[i] & 0xff);
> 117:         }
> 118:         fmt.format("%n    };%n");

You might find that java.util.HexFormat would be useful here.

import java.util.HexFormat;

HexFormat hex = HexFormat.ofDelimiter(", ").withPrefix("(byte)%x");
for (int i = 0; i < bytes.length; i += linelen) {
    System.out.print(" ".repeat(linelen));
    System.out.println(hex.formatHex(bytes, i, Math.min(i + linelen, bytes.length)));
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1358435078

From mcimadamore at openjdk.org  Fri Oct 13 15:50:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 15:50:12 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl
Message-ID: 

This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
Doing so addresses a possible deadlock condition when using multiple threads.

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

Commit messages:
 - Add test
 - Add copyright
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/16187/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16187&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317514
  Stats: 484 lines in 12 files changed: 313 ins; 147 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16187/head:pull/16187

PR: https://git.openjdk.org/jdk/pull/16187

From lancea at openjdk.org  Fri Oct 13 16:16:58 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Oct 2023 16:16:58 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v4]
In-Reply-To: 
References: 
 
Message-ID: <-43rxoWw0oS6F3TBhjoOfNoIgNuQ9esIQCA8wD6IYOc=.be53c463-02c9-4145-9b06-62bd7c7a4515@github.com>

On Fri, 13 Oct 2023 12:18:41 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor test edits and comment updates

Thank you for driving this issue Sean.

Overall I think it looks good.

Please see my minor comment below which you can handle prior to pushing the PR

test/jdk/java/util/zip/ZipFile/ZipSourceCache.java line 63:

> 61: 
> 62:     @Test
> 63:     public static void test() throws Exception {

Perhaps give the test a better name and add a brief comment block at least to the test method as we have been trying to add more clarity to the new tests that we add

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16115#pullrequestreview-1667211269
PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1352165848

From rriggs at openjdk.org  Fri Oct 13 16:26:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 13 Oct 2023 16:26:57 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 12:21:28 GMT, Mahendra Chhipa  wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tests with base64 input are removed.

test/jdk/javax/xml/jaxp/datatype/8033980/GregorianCalAndDurSerDataTemplate.java line 28:

> 26:  */
> 27: public class GregorianCalAndDurSerDataTemplate {
> 28:     public static final String GREGO_CAL_DUR_SER_CLASS = "public class %sGregorianCalendarAndDurationSerData extends GregorianCalendarAndDurationSerData {\n" +

These files should have a comment indicating they are generated and should not be edited.
And to avoid any manual steps, should include the full copyright with the year generated.

Like:


// -- This file was mechanically generated: Do not edit! -- //

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1358483378

From jvernee at openjdk.org  Fri Oct 13 16:30:39 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 16:30:39 GMT
Subject: RFR: 8317837: Leftover FFM implementation-only changes [v2]
In-Reply-To: 
References: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 12:18:59 GMT, Jorn Vernee  wrote:

>> Port of miscellaneous leftover implementation-only changes from the panama-foreign repo:
>> 
>> These four related to improving the performance of the internal `strlen` implementation:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/862
>>   - https://github.com/openjdk/panama-foreign/pull/860
>>   - https://github.com/openjdk/panama-foreign/pull/858
>>   - https://github.com/openjdk/panama-foreign/pull/857
>>   
>> Adding new benchmarks:
>>   
>>   - https://github.com/openjdk/panama-foreign/pull/874
>>   - https://github.com/openjdk/panama-foreign/pull/870
>> 
>> Other misc. changes:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/885
>>   - https://github.com/openjdk/panama-foreign/pull/886
>>   - https://github.com/openjdk/panama-foreign/pull/864
>>   - https://github.com/openjdk/panama-foreign/pull/903
>>   - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a javadoc block in the implementation only)
>>   - https://github.com/openjdk/panama-foreign/pull/908
>>   - https://github.com/openjdk/panama-foreign/pull/910
>>   
>> Testing: `jdk_foreign`
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315041: Optimize Java to C string conversion by avoiding double copy
>   
>   Reviewed-by: pminborg

Yes, both of those are planned for the style-only PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16128#issuecomment-1761787896

From jvernee at openjdk.org  Fri Oct 13 16:52:11 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 16:52:11 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 15:39:06 GMT, Maurizio Cimadamore  wrote:

>> This PR is based on a port of: openjdk/panama-foreign#898
>> 
>> Some additional changes are contained in this PR:
>> 
>> * instead of using a different "always alive" scope for zero-length memory segments, we now use the global scope
>> * the javadoc for `MemorySegment::ofArray`, `MemorySegment::ofBuffer` and `SymbolLookup::loaderLookup` is tweaked to say that the scope associated to the returned segments is an automatic scope
>> * the javadoc for `MemorySegment.Scope` defines the concepts of global and automatic scope, which are then referenced in the `Arena` javadoc.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/foreign/Arena.java line 47:

> 45:  * The simplest arena is the {@linkplain Arena#global() global arena}. The global arena
> 46:  * features an unbounded lifetime. The scope of the global arena is the global scope.
> 47:  * As such, native segments allocated with the global arena are associated are always accessible and their backing regions

Typo?
Suggestion:

 * As such, native segments allocated with the global arena are always accessible and their backing regions

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 463:

> 461:      * 

> 462:      * If the selected layout is an {@linkplain AddressLayout address layout}, calling {@link VarHandle#get(Object...)}
> 463:      * on the returned var handle will return a new memory segment. The segment is associated with a scope that is

Should this say 'global scope' as well?

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2367:

> 2365:      * A scope models the lifetime of all the memory segments associated with it. That is, a memory segment
> 2366:      * cannot be accessed if its associated scope is not {@linkplain #isAlive() alive}. Scope instances can be compared
> 2367:      * for equality. That is, two scopes are considered {@linkplain #equals(Object)} if they denote the same lifetime.

missing plain text in the link tag

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

PR Review: https://git.openjdk.org/jdk/pull/16183#pullrequestreview-1676868842
PR Review Comment: https://git.openjdk.org/jdk/pull/16183#discussion_r1358496679
PR Review Comment: https://git.openjdk.org/jdk/pull/16183#discussion_r1358498568
PR Review Comment: https://git.openjdk.org/jdk/pull/16183#discussion_r1358500044

From duke at openjdk.org  Fri Oct 13 17:01:11 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 13 Oct 2023 17:01:11 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: 

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use % calculate lowInt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/9dda9f70..88b1b13c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From jvernee at openjdk.org  Fri Oct 13 17:10:14 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 17:10:14 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 15:37:00 GMT, Maurizio Cimadamore  wrote:

> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
> Doing so addresses a possible deadlock condition when using multiple threads.

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1289:

> 1287:      * A zero-length native segment modelling the {@code NULL} address.
> 1288:      */
> 1289:     MemorySegment NULL = MemorySegment.ofAddress(0L);

The old no-arg constructor can now be removed from NativeMemroySegmentImpl as well I believe.

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

PR Review: https://git.openjdk.org/jdk/pull/16187#pullrequestreview-1676911705
PR Review Comment: https://git.openjdk.org/jdk/pull/16187#discussion_r1358523909

From mcimadamore at openjdk.org  Fri Oct 13 17:16:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 17:16:10 GMT
Subject: RFR: 8317837: Leftover FFM implementation-only changes [v2]
In-Reply-To: 
References: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 12:18:59 GMT, Jorn Vernee  wrote:

>> Port of miscellaneous leftover implementation-only changes from the panama-foreign repo:
>> 
>> These four related to improving the performance of the internal `strlen` implementation:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/862
>>   - https://github.com/openjdk/panama-foreign/pull/860
>>   - https://github.com/openjdk/panama-foreign/pull/858
>>   - https://github.com/openjdk/panama-foreign/pull/857
>>   
>> Adding new benchmarks:
>>   
>>   - https://github.com/openjdk/panama-foreign/pull/874
>>   - https://github.com/openjdk/panama-foreign/pull/870
>> 
>> Other misc. changes:
>> 
>>   - https://github.com/openjdk/panama-foreign/pull/885
>>   - https://github.com/openjdk/panama-foreign/pull/886
>>   - https://github.com/openjdk/panama-foreign/pull/864
>>   - https://github.com/openjdk/panama-foreign/pull/903
>>   - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a javadoc block in the implementation only)
>>   - https://github.com/openjdk/panama-foreign/pull/908
>>   - https://github.com/openjdk/panama-foreign/pull/910
>>   
>> Testing: `jdk_foreign`
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315041: Optimize Java to C string conversion by avoiding double copy
>   
>   Reviewed-by: pminborg

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16128#pullrequestreview-1676938254

From mcimadamore at openjdk.org  Fri Oct 13 17:16:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 17:16:09 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline) [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR is based on a port of: openjdk/panama-foreign#898
> 
> Some additional changes are contained in this PR:
> 
> * instead of using a different "always alive" scope for zero-length memory segments, we now use the global scope
> * the javadoc for `MemorySegment::ofArray`, `MemorySegment::ofBuffer` and `SymbolLookup::loaderLookup` is tweaked to say that the scope associated to the returned segments is an automatic scope
> * the javadoc for `MemorySegment.Scope` defines the concepts of global and automatic scope, which are then referenced in the `Arena` javadoc.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16183/files
  - new: https://git.openjdk.org/jdk/pull/16183/files/a9de77cd..81e6560d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16183&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16183&range=01-02

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16183/head:pull/16183

PR: https://git.openjdk.org/jdk/pull/16183

From mcimadamore at openjdk.org  Fri Oct 13 17:16:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 17:16:11 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline) [v3]
In-Reply-To: 
References: 
 
Message-ID: <-YyNQ32bER-iAroLft4A7MTq-S42-ovBcEXsikQcAFc=.7506326e-0e79-4bd4-b3ba-73879d926dbf@github.com>

On Fri, 13 Oct 2023 17:10:48 GMT, Maurizio Cimadamore  wrote:

>> This PR is based on a port of: openjdk/panama-foreign#898
>> 
>> Some additional changes are contained in this PR:
>> 
>> * instead of using a different "always alive" scope for zero-length memory segments, we now use the global scope
>> * the javadoc for `MemorySegment::ofArray`, `MemorySegment::ofBuffer` and `SymbolLookup::loaderLookup` is tweaked to say that the scope associated to the returned segments is an automatic scope
>> * the javadoc for `MemorySegment.Scope` defines the concepts of global and automatic scope, which are then referenced in the `Arena` javadoc.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 484:

> 482:      * VarHandle baseHandle = this.varHandle(P);
> 483:      * MemoryLayout target = ((AddressLayout)this.select(P)).targetLayout().get();
> 484:      * VarHandle targetHandle = target.varHandle(P);

I've seen this typo in the example, and decided to fix it (even if unrelated)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16183#discussion_r1358528040

From jvernee at openjdk.org  Fri Oct 13 17:20:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 17:20:10 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline) [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 17:16:09 GMT, Maurizio Cimadamore  wrote:

>> This PR is based on a port of: openjdk/panama-foreign#898
>> 
>> Some additional changes are contained in this PR:
>> 
>> * instead of using a different "always alive" scope for zero-length memory segments, we now use the global scope
>> * the javadoc for `MemorySegment::ofArray`, `MemorySegment::ofBuffer` and `SymbolLookup::loaderLookup` is tweaked to say that the scope associated to the returned segments is an automatic scope
>> * the javadoc for `MemorySegment.Scope` defines the concepts of global and automatic scope, which are then referenced in the `Arena` javadoc.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16183#pullrequestreview-1676967968

From mcimadamore at openjdk.org  Fri Oct 13 17:31:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 17:31:15 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
> Doing so addresses a possible deadlock condition when using multiple threads.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16187/files
  - new: https://git.openjdk.org/jdk/pull/16187/files/2aad11cf..b9ad352b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16187&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16187&range=00-01

  Stats: 12 lines in 2 files changed: 0 ins; 11 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16187/head:pull/16187

PR: https://git.openjdk.org/jdk/pull/16187

From jvernee at openjdk.org  Fri Oct 13 17:31:16 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 17:31:16 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl [v2]
In-Reply-To: 
References: 
 
Message-ID: <77pUHxjLJRpzN6PqTTlTW7t6wXKtSSFKGpXVVweEeao=.ac315f09-33be-4f43-9169-2599f6c58b41@github.com>

On Fri, 13 Oct 2023 17:25:03 GMT, Maurizio Cimadamore  wrote:

>> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
>> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
>> Doing so addresses a possible deadlock condition when using multiple threads.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16187#pullrequestreview-1676985669

From pminborg at openjdk.org  Fri Oct 13 17:48:09 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Oct 2023 17:48:09 GMT
Subject: RFR: 8317514: Ensure MemorySegment is initialized before touching
 NativeMemorySegmentImpl [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 17:31:15 GMT, Maurizio Cimadamore  wrote:

>> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
>> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
>> Doing so addresses a possible deadlock condition when using multiple threads.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 49:

> 47:  */
> 48: public class SegmentFactories {
> 49: 

We could make this a proper utility class by declaring the class final and having a private constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16187#discussion_r1358610000

From duke at openjdk.org  Fri Oct 13 18:46:08 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 13 Oct 2023 18:46:08 GMT
Subject: RFR: 8318072: DonwcallLinker does not acquire/release segments in
 interpreter
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 08:00:07 GMT, Jorn Vernee  wrote:

> Implement missing by-reference argument acquire/release functionality in DowncallLinker::invokeInterpBindings.
> 
> I've also simplified the related code a bit:
> - `retIndexMap` was not used. I've removed it
> - `BindingInterpreter.StoreFunc::store`'s type argument was not used. Removed
> - UpcallLinker was redundantly collecting the move bindings for return values. Removed
> 
> I've added runs without specialization to the failing tests as well, so that we keep testing this.
> 
> Testing: `jdk_foreign` suite.

DowncallLinker is not spelled correctly in the PR and JBS issue. Fixing this could improve searchability.

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

PR Comment: https://git.openjdk.org/jdk/pull/16177#issuecomment-1762026584

From jvernee at openjdk.org  Fri Oct 13 19:11:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 19:11:21 GMT
Subject: Integrated: 8317824: Beef up javadoc for base offset in var handles
 derived from layouts (mainline)
In-Reply-To: 
References: 
Message-ID: <1qKYZrgidg76nqzlOQwFpe7Foaa7VH9DYhsjYF5lcyM=.f0115fae-5c40-45f9-aec4-478e15526db9@github.com>

On Tue, 10 Oct 2023 17:58:12 GMT, Jorn Vernee  wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/901
> 
> Original PR body:
> 
>> This PR adds more javadoc to explain how base offsets in var handles obtained from layouts can be used.
>> 
>> First, a number of examples in the main `MemoryLayout` javadoc is rectified, as such examples did not use the additional base offset parameter (and were hence incorrect).
>> 
>> Second, the var handles part in the `MemorySegment` section on "accessing memory segment" has been rewritten to avoid duplication with the concepts exposed in `MemoryLayout`. Now we show how `MemorySegment::get` and `MemorySegment::getAtIndex` can be obtained using basic var handles and combinators. We mention that more complex var handles can be obtained using layout paths, but we now just reference the layout path section.
>> 
>> Last, I've added a new section on the `MemoryLayout` javadoc, with an example on how to deal with variable-length structs. This example showcases how var handles can be used in intricate situations, and combined with the new `scaleOffset` method.

This pull request has now been integrated.

Changeset: 32a60cf1
Author:    Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/32a60cf11d08aa34592269e6e9bdd7453583a8ad
Stats:     123 lines in 2 files changed: 78 ins; 17 del; 28 mod

8317824: Beef up javadoc for base offset in var handles derived from layouts (mainline)

Co-authored-by: Maurizio Cimadamore 
Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/16127

From jvernee at openjdk.org  Fri Oct 13 19:11:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 13 Oct 2023 19:11:30 GMT
Subject: Integrated: 8317837: Leftover FFM implementation-only changes
In-Reply-To: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
References: <9pxo-WY8TH0LMP55BuolpB4ajAMMK00KgsXgjPbjBns=.5a9e0f5f-179c-4290-bf96-ff2c5f53ab01@github.com>
Message-ID: 

On Tue, 10 Oct 2023 21:41:01 GMT, Jorn Vernee  wrote:

> Port of miscellaneous leftover implementation-only changes from the panama-foreign repo:
> 
> These four related to improving the performance of the internal `strlen` implementation:
> 
>   - https://github.com/openjdk/panama-foreign/pull/862
>   - https://github.com/openjdk/panama-foreign/pull/860
>   - https://github.com/openjdk/panama-foreign/pull/858
>   - https://github.com/openjdk/panama-foreign/pull/857
>   
> Adding new benchmarks:
>   
>   - https://github.com/openjdk/panama-foreign/pull/874
>   - https://github.com/openjdk/panama-foreign/pull/870
> 
> Other misc. changes:
> 
>   - https://github.com/openjdk/panama-foreign/pull/885
>   - https://github.com/openjdk/panama-foreign/pull/886
>   - https://github.com/openjdk/panama-foreign/pull/864
>   - https://github.com/openjdk/panama-foreign/pull/903
>   - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a javadoc block in the implementation only)
>   - https://github.com/openjdk/panama-foreign/pull/908
>   - https://github.com/openjdk/panama-foreign/pull/910
>   
> Testing: `jdk_foreign`

This pull request has now been integrated.

Changeset: b12c471a
Author:    Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/b12c471a990eb8f789410a20084918368c655659
Stats:     1443 lines in 22 files changed: 1332 ins; 15 del; 96 mod

8317837: Leftover FFM implementation-only changes

Co-authored-by: Maurizio Cimadamore 
Co-authored-by: Per Minborg 
Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/16128

From redestad at openjdk.org  Fri Oct 13 19:41:11 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 13 Oct 2023 19:41:11 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

src/java.base/share/classes/java/math/BigDecimal.java line 4162:

> 4160:             int highInt = (int)intCompact / 100;
> 4161:             short pair = DecimalDigits.digitPair((int)intCompact % 100);
> 4162:             return "" + highInt + '.' + (char)(pair & 0xff) + (char)(pair >> 8);

FTR: while this works (since `pair` is never negative), casting `pair` to `char` or changing to `(char)((pair >> 8) & 0xff)` would be necessary for the general case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16006#discussion_r1358751744

From jlu at openjdk.org  Fri Oct 13 20:51:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Oct 2023 20:51:59 GMT
Subject: Integrated: JDK-8317372: Refactor some NumberFormat tests to use JUnit
In-Reply-To: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
Message-ID: 

On Tue, 3 Oct 2023 22:23:11 GMT, Justin Lu  wrote:

> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
> 
> During the switch to JUnit, the tests had the following updates (to improve readability)
> - separate the test data generation from the actual execution of the test
> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

This pull request has now been integrated.

Changeset: 9622de2a
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/9622de2aa89923b8444df093ae1c596bc336f14f
Stats:     943 lines in 9 files changed: 390 ins; 195 del; 358 mod

8317372: Refactor some NumberFormat tests to use JUnit

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/16035

From mcimadamore at openjdk.org  Fri Oct 13 21:30:13 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 13 Oct 2023 21:30:13 GMT
Subject: Integrated: 8317514: Ensure MemorySegment is initialized before
 touching NativeMemorySegmentImpl
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 15:37:00 GMT, Maurizio Cimadamore  wrote:

> This PR makes sure that `MemorySegment` is initialized *before* any of its subclasses.
> This is done by centralizing all the memory segment factories in a single implementation class (`SegmentFactories`).
> Doing so addresses a possible deadlock condition when using multiple threads.

This pull request has now been integrated.

Changeset: 7cb2e6d6
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/7cb2e6d65b517b638a584149560a2ff9cc56c3b6
Stats:     496 lines in 12 files changed: 313 ins; 158 del; 25 mod

8317514: Ensure MemorySegment is initialized before touching NativeMemorySegmentImpl

Co-authored-by: Jorn Vernee 
Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jdk/pull/16187

From sviswanathan at openjdk.org  Fri Oct 13 23:02:37 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 13 Oct 2023 23:02:37 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 
 <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 10:31:14 GMT, himichael  wrote:

>> @himichael Please refer to [this question](https://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java) for how to correctly benchmark Java code.
>
>> @himichael Please refer to [this question](https://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java) for how to correctly benchmark Java code.   
> 
> thanks for your reply, but I think this has nothing to do with benchmark.   
> I sort a random array of int[], use: ```java.util.Arrays.sort()```    
> in jdk 8, run command:  
> ```java JDKSort``` , the result display: 15079 ms   
>    
> in open jdk 22.19 , run command:   
> ```java --add-modules jdk.incubator.vector JDKSort```   
> the result display:  11619 ms     
>    
> my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8.   
> is there a problem with my configuration ?

@himichael Please try java -Xbatch -XX:-TieredCompilation JDKSort. The method DualPivotQuickSort.sort() needs to be C2 compiled for you to see the benefit.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1762361069

From duke at openjdk.org  Fri Oct 13 23:53:03 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 13 Oct 2023 23:53:03 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

Under linux OS and Intel Xeon Platinum 8475B, the performance of testSmallToEngineeringString becomes slower. It may be a better choice when using JLA.

## Alibaba Cloud Linux 3.2104 LTS 64 bit (Intel Xeon Platinum 8475B)

-Benchmark                                 Mode  Cnt     Score   Error  Units (baseline)
-BigDecimals.testHugeToEngineeringString   avgt   15   206.519 ? 1.574  ns/op
-BigDecimals.testLargeToEngineeringString  avgt   15    35.830 ? 3.008  ns/op
-BigDecimals.testSmallToEngineeringString  avgt   15    15.048 ? 0.033  ns/op
-BigDecimals.testToEngineeringString       avgt   15  1738.627 ? 3.723  ns/op

+Benchmark                                 Mode  Cnt     Score   Error  Units (88b1b13)
+BigDecimals.testHugeToEngineeringString   avgt   15   179.174 ? 0.496  ns/op (+15.27)
+BigDecimals.testLargeToEngineeringString  avgt   15    28.282 ? 0.050  ns/op (+26.69)
+BigDecimals.testSmallToEngineeringString  avgt   15    17.106 ? 0.043  ns/op (-12.04)
+BigDecimals.testToEngineeringString       avgt   15  1679.343 ? 6.285  ns/op (+3.54)


## MacBook M1 Pro

-Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
-BigDecimals.testHugeToEngineeringString   avgt   15   213.017 ? 24.056  ns/op
-BigDecimals.testLargeToEngineeringString  avgt   15    58.025 ?  4.403  ns/op
-BigDecimals.testSmallToEngineeringString  avgt   15    17.232 ?  0.484  ns/op
-BigDecimals.testToEngineeringString       avgt   15  1767.594 ? 43.153  ns/op

+Benchmark                                 Mode  Cnt     Score    Error  Units (88b1b13)
+BigDecimals.testHugeToEngineeringString   avgt   15   149.861 ?  1.092  ns/op (+42.15)
+BigDecimals.testLargeToEngineeringString  avgt   15    21.307 ?  0.062  ns/op (+172.33)
+BigDecimals.testSmallToEngineeringString  avgt   15    16.875 ?  0.047  ns/op (+2.12)
+BigDecimals.testToEngineeringString       avgt   15  1703.302 ? 44.969  ns/op (+3.78)

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1762382844

From duke at openjdk.org  Sat Oct 14 00:03:48 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Sat, 14 Oct 2023 00:03:48 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 
 <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 10:31:14 GMT, himichael  wrote:

> my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8. is there a problem with my configuration ?

Hello @himichael,

Using your code snippet, please see the output below using the latest JDK and JDK 20 (which does not have AVX512 sort):

JDK 20 (without AVX512 sort): 
`java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort `

elapse time -> **7501 ms**

------------------------------
JDK 22 (with AVX512 sort)
`java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort`
elapse time -> **1607 ms**

It shows 4.66x speedup.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1762406455

From duke at openjdk.org  Sat Oct 14 03:25:34 2023
From: duke at openjdk.org (himichael)
Date: Sat, 14 Oct 2023 03:25:34 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
 
 <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>
 
 
Message-ID: <_MGkyOjyeyCIOE_HpYGCpzN3zN6bJEtaMGo_3T66e7M=.446e6122-c301-4dd9-9704-b72606275f4c@github.com>

On Fri, 13 Oct 2023 23:59:55 GMT, Srinivas Vamsi Parasa  wrote:

> > my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8. is there a problem with my configuration ?
> 
> Hello @himichael,
> 
> Using your code snippet, please see the output below using the latest JDK and JDK 20 (which does not have AVX512 sort):
> 
> JDK 20 (without AVX512 sort): `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort `
> 
> elapse time -> **7501 ms**
> 
> JDK 22 (with AVX512 sort) `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort` elapse time -> **1607 ms**
> 
> It shows 4.66x speedup.

Hello, @vamsi-parasa 
I used the commands you provided, but nothing seems to have changed.   
The test procedure as follow:   
use JDK 8(without AVX512 sort)   

/data/soft/jdk1.8.0_371/bin/javac  JDKSort.java
/data/soft/jdk1.8.0_371/bin/java  JDKSort

elapse time -> **15309 ms**   
   
use OpenJDK 22.19(with AVX512 sort)   

/data/soft/jdk-22/bin/javac JDKSort.java
/data/soft/jdk-22/bin/java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort
CompileCommand: CompileThresholdScaling java/util/DualPivotQuicksort.sort double CompileThresholdScaling = 0.000100

elapse time -> **11687 ms**
   
Not much seems to have changed.   

My JDK info:   
OpenJDK 22.19:

/data/soft/jdk-22/bin/java -version
openjdk version "22-ea" 2024-03-19
OpenJDK Runtime Environment (build 22-ea+19-1460)
OpenJDK 64-Bit Server VM (build 22-ea+19-1460, mixed mode, sharing)


JDK 8:

/data/soft/jdk1.8.0_371/bin/java -version
java version "1.8.0_371"
Java(TM) SE Runtime Environment (build 1.8.0_371-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.371-b11, mixed mode)



I tested Intel's **x86-simd-sort**, my code as follow:
```c++
#include 
#include 
#include 
#include 
#include "src/avx512-32bit-qsort.hpp"

int main() {

    // 100 million records
    const int size = 100000000;
    std::vector random_array(size);

    for (int i = 0; i < size; ++i) {
        random_array[i] = rand();
    }

    auto start_time = std::chrono::steady_clock::now();

    avx512_qsort(random_array.data(), size);

    auto end_time = std::chrono::steady_clock::now();
    auto elapse_time = std::chrono::duration_cast(end_time - start_time).count();

    std::cout << "elapse time -> " << elapse_time << " ms" << std::endl;
    return 0;
}

compile commands:   

g++ -o sort -O3 -mavx512f -mavx512dq sort.cpp

elapse time -> **1151 ms**  
An order of magnitude performance improvement.   

Here is my cpu information:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             8
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel Xeon Processor (Skylake, IBRS)
Stepping:              4
CPU MHz:               2394.374
BogoMIPS:              4788.74
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
NUMA node0 CPU(s):     0-7
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 md_clear spec_ctrl

```lscpu | grep avx```  The following instructions are supported:
- avx
- avx2
- avx512f
- avx512dq
- avx512cd
- avx512bw
- avx512vl

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1762543464

From qamai at openjdk.org  Sat Oct 14 05:06:44 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 14 Oct 2023 05:06:44 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: <_MGkyOjyeyCIOE_HpYGCpzN3zN6bJEtaMGo_3T66e7M=.446e6122-c301-4dd9-9704-b72606275f4c@github.com>
References: 
 
 
 <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>
 
 
 <_MGkyOjyeyCIOE_HpYGCpzN3zN6bJEtaMGo_3T66e7M=.446e6122-c301-4dd9-9704-b72606275f4c@github.com>
Message-ID: 

On Sat, 14 Oct 2023 03:21:52 GMT, himichael  wrote:

>>> my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8. is there a problem with my configuration ?
>> 
>> Hello @himichael,
>> 
>> Using your code snippet, please see the output below using the latest JDK and JDK 20 (which does not have AVX512 sort):
>> 
>> JDK 20 (without AVX512 sort): 
>> `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort `
>> 
>> elapse time -> **7501 ms**
>> 
>> ------------------------------
>> JDK 22 (with AVX512 sort)
>> `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort`
>> elapse time -> **1607 ms**
>> 
>> It shows 4.66x speedup.
>
>> > my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8. is there a problem with my configuration ?
>> 
>> Hello @himichael,
>> 
>> Using your code snippet, please see the output below using the latest JDK and JDK 20 (which does not have AVX512 sort):
>> 
>> JDK 20 (without AVX512 sort): `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort `
>> 
>> elapse time -> **7501 ms**
>> 
>> JDK 22 (with AVX512 sort) `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort` elapse time -> **1607 ms**
>> 
>> It shows 4.66x speedup.
> 
> Hello, @vamsi-parasa 
> I used the commands you provided, but nothing seems to have changed.   
> The test procedure as follow:   
> use JDK 8(without AVX512 sort)   
> 
> /data/soft/jdk1.8.0_371/bin/javac  JDKSort.java
> /data/soft/jdk1.8.0_371/bin/java  JDKSort
> 
> elapse time -> **15309 ms**   
>    
> use OpenJDK 22.19(with AVX512 sort)   
> 
> /data/soft/jdk-22/bin/javac JDKSort.java
> /data/soft/jdk-22/bin/java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort
> CompileCommand: CompileThresholdScaling java/util/DualPivotQuicksort.sort double CompileThresholdScaling = 0.000100
> 
> elapse time -> **11687 ms**
>    
> Not much seems to have changed.   
> 
> My JDK info:   
> OpenJDK 22.19:
> 
> /data/soft/jdk-22/bin/java -version
> openjdk version "22-ea" 2024-03-19
> OpenJDK Runtime Environment (build 22-ea+19-1460)
> OpenJDK 64-Bit Server VM (build 22-ea+19-1460, mixed mode, sharing)
> 
> 
> JDK 8:
> 
> /data/soft/jdk1.8.0_371/bin/java -version
> java version "1.8.0_371"
> Java(TM) SE Runtime Environment (build 1.8.0_371-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.371-b11, mixed mode)
> 
> 
> 
> I tested Intel's **x86-simd-sort**, my code as follow:
> ```c++
> #include 
> #include 
> #include 
> #include 
> #include "src/avx512-32bit-qsort.hpp"
> 
> int main() {
> 
>     // 100 million records
>     const int size = 100000000;
>     std::vector random_array(size);
> 
>     for (int i = 0; i < size; ++i) {
>         random_array[i] = rand();
>     }
> 
>     auto start_time = std::chrono::steady_clock::now();
> 
>     avx512_qsort(random_array.data(), size);
> 
>     auto end_time = std::chrono::steady_clock::now();
>     auto elapse_time = std::chrono::duration_cast(end_time - start_time)....

@himichael What do you mean by this having nothing to do with benchmark. You are trying to execute some code to measure its execution time, which is benchmarking. And you are doing that on only 1 simple function, which makes your benchmark micro.

To be more specific, this is a C2-specific optimisation, so only C2-compiled code is benefitted from it. As a result, you need to have the function compiled BEFORE starting the clock. Typically, this is ensured by executing the function repeatedly for several iterations (the current default value is 20000), starting the clock, executing the function several more times, stopping the clock and calculating the average throughput. As this is quite complex and contains non-trivial caveats, it is recommended to use JMH for microbenchmarks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1762598167

From duke at openjdk.org  Sat Oct 14 05:55:08 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 14 Oct 2023 05:55:08 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

Core-libs has duplicate codes for stringSize and getChars in many places, such as:

* java.math.BigDecimal$StringBuilderHelper
* jdk.util.DecimalDigits
* java.time.format.DateTimeFormatterBuilder$NanosPrinterParser

We have two options to reduce duplicate code:
1. Provide the stringSize method of Integer/Long and the getChars method of StringLatin1/StringUTF168 through JLA.
2. Move the stringSize method of Integer/Long and the getChars method of StringLatin1/StringUTF168 to jdk.util.DecimalDigits (PR #15699 )

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1762634035

From duke at openjdk.org  Sat Oct 14 07:13:59 2023
From: duke at openjdk.org (duke)
Date: Sat, 14 Oct 2023 07:13:59 GMT
Subject: Withdrawn: 8314515:
 java/util/concurrent/SynchronousQueue/Fairness.java failed with
 "Error: fair=false i=8 j=0"
In-Reply-To: <6yvA_1UW9arwLh-HQqllCe04KtMlpNc_pRwV5fjpnP0=.01b1313c-0dc8-4f45-84e2-07ee3fdcf63f@github.com>
References: <6yvA_1UW9arwLh-HQqllCe04KtMlpNc_pRwV5fjpnP0=.01b1313c-0dc8-4f45-84e2-07ee3fdcf63f@github.com>
Message-ID: 

On Thu, 17 Aug 2023 22:35:39 GMT, Martin Buchholz  wrote:

> The usual tiny improvements, with no guarantee that the intermittent test failure is actually fixed.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/15337

From mdoerr at openjdk.org  Sat Oct 14 13:57:51 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 14 Oct 2023 13:57:51 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
 
 <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>
 
 
Message-ID: 

On Fri, 13 Oct 2023 14:48:51 GMT, Martin Doerr  wrote:

>> Discussed this a bit with Maurizio. There are a few things to consider:
>> 
>> - `cannonicalLayouts` allows for just a single mapping from type name to layout. I think `double` should map to the 8-byte aligned layout. (the same alignment you get from `_Alignof(double)` in C).
>> - We have to relax the checking done by the linker on AIX. Maybe change `AbstractLinker::checkLayoutRecursive` call some `checkStructMemberLayout` method, that by default just calls `checkLayoutRecursive`, but which the AIX linker can override to implement its special rules for doubles.
>> - We need a small spec update to allow for struct field layouts that are not canonical layouts. I'll take a stab at that, and then get back to you.
>
> Thanks for your outstanding support! I'm awaiting feedback from IBM and a solution for the subtask https://bugs.openjdk.org/browse/JDK-8317799. There shouldn't be much work to be done after that, I guess.

So, your proposal should look like this?

diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
index dbd9a3f67a4..ec1639938e8 100644
--- a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
+++ b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
@@ -180,6 +180,11 @@ private void checkLayout(MemoryLayout layout) {
         }
     }
 
+    // Platforms can override.
+    protected MemoryLayout processGroupLayoutMember(MemoryLayout member, long offset) {
+        return member;
+    }
+
     private void checkLayoutRecursive(MemoryLayout layout) {
         if (layout instanceof ValueLayout vl) {
             checkSupported(vl);
@@ -191,6 +196,7 @@ private void checkLayoutRecursive(MemoryLayout layout) {
                 // check element offset before recursing so that an error points at the
                 // outermost layout first
                 checkMemberOffset(sl, member, lastUnpaddedOffset, offset);
+                member = processGroupLayoutMember(member, offset);
                 checkLayoutRecursive(member);
 
                 offset += member.byteSize();
diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
index c24d2553ec0..ddd4049c814 100644
--- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
+++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
@@ -46,7 +46,7 @@ public final class AixPPC64Linker extends AbstractLinker {
     static {
         HashMap layouts = new HashMap<>();
         layouts.putAll(SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT));
-        layouts.put("double", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
+        layouts.put("double4bytealigned", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
         CANONICAL_LAYOUTS = Map.copyOf(layouts);
     }
 
@@ -81,4 +81,13 @@ protected ByteOrder linkerByteOrder() {
     public Map canonicalLayouts() {
         return CANONICAL_LAYOUTS;
     }
+
+    @Override
+    protected MemoryLayout processGroupLayoutMember(MemoryLayout member, long offset) {
+        // Change alignment of double members to 4 except at the beginning.
+        if ((offset > 0) && (member instanceof ValueLayout vl && vl.carrier() == double.class)) {
+            return ValueLayout.JAVA_DOUBLE.withByteAlignment(4);
+        }
+        return member;
+    }
 }

That will require AIX specific changes in the tests which use double values in structures. Should we use the `double4bytealigned` only on AIX in these tests or what do you suggest?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1359400910

From jvernee at openjdk.org  Sat Oct 14 16:59:50 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 14 Oct 2023 16:59:50 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
 
 <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>
 
 
 
Message-ID: 

On Sat, 14 Oct 2023 13:54:28 GMT, Martin Doerr  wrote:

>> Thanks for your outstanding support! I'm awaiting feedback from IBM and a solution for the subtask https://bugs.openjdk.org/browse/JDK-8317799. There shouldn't be much work to be done after that, I guess.
>
> So, your proposal should look like this?
> 
> diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
> index dbd9a3f67a4..ec1639938e8 100644
> --- a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
> +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
> @@ -180,6 +180,11 @@ private void checkLayout(MemoryLayout layout) {
>          }
>      }
>  
> +    // Platforms can override.
> +    protected MemoryLayout processGroupLayoutMember(MemoryLayout member, long offset) {
> +        return member;
> +    }
> +
>      private void checkLayoutRecursive(MemoryLayout layout) {
>          if (layout instanceof ValueLayout vl) {
>              checkSupported(vl);
> @@ -191,6 +196,7 @@ private void checkLayoutRecursive(MemoryLayout layout) {
>                  // check element offset before recursing so that an error points at the
>                  // outermost layout first
>                  checkMemberOffset(sl, member, lastUnpaddedOffset, offset);
> +                member = processGroupLayoutMember(member, offset);
>                  checkLayoutRecursive(member);
>  
>                  offset += member.byteSize();
> diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
> index c24d2553ec0..ddd4049c814 100644
> --- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
> +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
> @@ -46,7 +46,7 @@ public final class AixPPC64Linker extends AbstractLinker {
>      static {
>          HashMap layouts = new HashMap<>();
>          layouts.putAll(SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT));
> -        layouts.put("double", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
> +        layouts.put("double4bytealigned", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
>          CANONICAL_LAYOUTS = Map.copyOf(layouts);
>      }
>  
> @@ -81,4 +81,13 @@ protected ByteOrder linkerByteOrder() {
>      public Map canonicalLayouts() {
>          return CANONICAL_LAYOUTS;
>      }
> +
> +    @Override
> +    protected MemoryLayout processGroupLayoutMember(MemoryLayout member, long offset) {
> +        // Change alignment of double members to 4 except at the beginning.
> +        if ((offse...

I was thinking something like this:


diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
index dbd9a3f67a4..10b371457b3 100644
--- a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
+++ b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
@@ -180,6 +180,11 @@ private void checkLayout(MemoryLayout layout) {
         }
     }
 
+    // some ABIs have special handling for struct members
+    protected void checkStructMember(MemoryLayout member, long offset) {
+        checkLayoutRecursive(member);
+    }
+
     private void checkLayoutRecursive(MemoryLayout layout) {
         if (layout instanceof ValueLayout vl) {
             checkSupported(vl);
@@ -191,7 +196,7 @@ private void checkLayoutRecursive(MemoryLayout layout) {
                 // check element offset before recursing so that an error points at the
                 // outermost layout first
                 checkMemberOffset(sl, member, lastUnpaddedOffset, offset);
-                checkLayoutRecursive(member);
+                checkStructMember(member, offset);
 
                 offset += member.byteSize();
                 if (!(member instanceof PaddingLayout)) {
diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
index c24d2553ec0..f70af2bc025 100644
--- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
+++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
@@ -36,19 +36,14 @@
 import java.lang.invoke.MethodHandle;
 import java.lang.invoke.MethodType;
 import java.nio.ByteOrder;
-import java.util.HashMap;
 import java.util.Map;
 
 public final class AixPPC64Linker extends AbstractLinker {
 
-    static final Map CANONICAL_LAYOUTS;
+    static final Map CANONICAL_LAYOUTS
+            = SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT);
 
-    static {
-        HashMap layouts = new HashMap<>();
-        layouts.putAll(SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT));
-        layouts.put("double", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
-        CANONICAL_LAYOUTS = Map.copyOf(layouts);
-    }
+    private static final MemoryLayout C_DOUBLE = CANONICAL_LAYOUTS.get("double");
 
     public static AixPPC64Linker getInstance() {
         final class Holder {
@@ -62,6 +57,19 @@ private AixPPC64Linker() {
         // Ensure there is only one instance
     }
 
+    @Override
+    protected void checkStructMember(MemoryLayout member, long offset) {
+        // special case double members that are not the first member
+        // see: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes
+        if ((offset > 0) && member.equals(C_DOUBLE)) {
+            if (member.byteAlignment() != 4) {
+                throw new IllegalArgumentException("double struct member following the first member should be 4-byte aligned");
+            }
+        } else {
+            super.checkStructMember(member, offset);
+        }
+    }
+
     @Override
     protected MethodHandle arrangeDowncall(MethodType inferredMethodType, FunctionDescriptor function, LinkerOptions options) {
         return CallArranger.AIX.arrangeDowncall(inferredMethodType, function, options);



I.e. there should not be a special 4-byte aligned canonical layout. Canonical layouts are for mapping native/C type names to memory layouts, and `double4bytealigned` is not such a name.

Then, with the above changes, you'd also need to change the tests to use the right double layouts when creating struct layouts on AIX. Note that that will also require changes to `jdk.internal.foreign.Utils::computePaddedStructLayout` which computes struct layouts for some of the tests (including all the `TestDowncall*` and `TestUpcall*` tests). In that method, there are a couple of calls to `l.byteAlignment()` that should be replaced by something that returns `4` for non-first double layouts on AIX.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1359480986

From jvernee at openjdk.org  Sat Oct 14 18:03:53 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 14 Oct 2023 18:03:53 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v2]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
 
 <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>
 
 
 
 
Message-ID: 

On Sat, 14 Oct 2023 16:56:50 GMT, Jorn Vernee  wrote:

>> So, your proposal should look like this?
>> 
>> diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>> index dbd9a3f67a4..ec1639938e8 100644
>> --- a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>> +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>> @@ -180,6 +180,11 @@ private void checkLayout(MemoryLayout layout) {
>>          }
>>      }
>>  
>> +    // Platforms can override.
>> +    protected MemoryLayout processGroupLayoutMember(MemoryLayout member, long offset) {
>> +        return member;
>> +    }
>> +
>>      private void checkLayoutRecursive(MemoryLayout layout) {
>>          if (layout instanceof ValueLayout vl) {
>>              checkSupported(vl);
>> @@ -191,6 +196,7 @@ private void checkLayoutRecursive(MemoryLayout layout) {
>>                  // check element offset before recursing so that an error points at the
>>                  // outermost layout first
>>                  checkMemberOffset(sl, member, lastUnpaddedOffset, offset);
>> +                member = processGroupLayoutMember(member, offset);
>>                  checkLayoutRecursive(member);
>>  
>>                  offset += member.byteSize();
>> diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
>> index c24d2553ec0..ddd4049c814 100644
>> --- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
>> +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
>> @@ -46,7 +46,7 @@ public final class AixPPC64Linker extends AbstractLinker {
>>      static {
>>          HashMap layouts = new HashMap<>();
>>          layouts.putAll(SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT));
>> -        layouts.put("double", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
>> +        layouts.put("double4bytealigned", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
>>          CANONICAL_LAYOUTS = Map.copyOf(layouts);
>>      }
>>  
>> @@ -81,4 +81,13 @@ protected ByteOrder linkerByteOrder() {
>>      public Map canonicalLayouts() {
>>          return CANONICAL_LAYOUTS;
>>      }
>> +
>> +    @Override
>> +    protected MemoryLayout processGroupLayoutMember(MemoryLayout member, long offset) {
>> + ...
>
> I was thinking something like this:
> 
> 
> diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
> index dbd9a3f67a4..10b371457b3 100644
> --- a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
> +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
> @@ -180,6 +180,11 @@ private void checkLayout(MemoryLayout layout) {
>          }
>      }
>  
> +    // some ABIs have special handling for struct members
> +    protected void checkStructMember(MemoryLayout member, long offset) {
> +        checkLayoutRecursive(member);
> +    }
> +
>      private void checkLayoutRecursive(MemoryLayout layout) {
>          if (layout instanceof ValueLayout vl) {
>              checkSupported(vl);
> @@ -191,7 +196,7 @@ private void checkLayoutRecursive(MemoryLayout layout) {
>                  // check element offset before recursing so that an error points at the
>                  // outermost layout first
>                  checkMemberOffset(sl, member, lastUnpaddedOffset, offset);
> -                checkLayoutRecursive(member);
> +                checkStructMember(member, offset);
>  
>                  offset += member.byteSize();
>                  if (!(member instanceof PaddingLayout)) {
> diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
> index c24d2553ec0..f70af2bc025 100644
> --- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
> +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
> @@ -36,19 +36,14 @@
>  import java.lang.invoke.MethodHandle;
>  import java.lang.invoke.MethodType;
>  import java.nio.ByteOrder;
> -import java.util.HashMap;
>  import java.util.Map;
>  
>  public final class AixPPC64Linker extends AbstractLinker {
>  
> -    static final Map CANONICAL_LAYOUTS;
> +    static final Map CANONICAL_LAYOUTS
> +            = SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT);
>  
> -    static {
> -        HashMap layouts = new HashMap<>();
> -        layouts.putAll(SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT));
> -        layouts.put("double", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
> -        CANONICAL_LAYOUTS = Map.copyOf(layo...

Err, actually using `member.equals(C_DOUBLE)` in the above doesn't work since it still checks alignment. What you have with checking for `ValueLayout` and `carrier() == double.class` is better, but the byte order should also be checked at some point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1359511273

From jvernee at openjdk.org  Sat Oct 14 20:26:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 14 Oct 2023 20:26:57 GMT
Subject: Integrated: 8318072: DowncallLinker does not acquire/release segments
 in interpreter
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 08:00:07 GMT, Jorn Vernee  wrote:

> Implement missing by-reference argument acquire/release functionality in DowncallLinker::invokeInterpBindings.
> 
> I've also simplified the related code a bit:
> - `retIndexMap` was not used. I've removed it
> - `BindingInterpreter.StoreFunc::store`'s type argument was not used. Removed
> - UpcallLinker was redundantly collecting the move bindings for return values. Removed
> 
> I've added runs without specialization to the failing tests as well, so that we keep testing this.
> 
> Testing: `jdk_foreign` suite.

This pull request has now been integrated.

Changeset: 1d54e73f
Author:    Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/1d54e73f6acf6e8fad674206b168c950d62c6f58
Stats:     64 lines in 6 files changed: 44 ins; 7 del; 13 mod

8318072: DowncallLinker does not acquire/release segments in interpreter

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/16177

From duke at openjdk.org  Sun Oct 15 05:36:51 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Sun, 15 Oct 2023 05:36:51 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: <_MGkyOjyeyCIOE_HpYGCpzN3zN6bJEtaMGo_3T66e7M=.446e6122-c301-4dd9-9704-b72606275f4c@github.com>
References: 
 
 
 <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>
 
 
 <_MGkyOjyeyCIOE_HpYGCpzN3zN6bJEtaMGo_3T66e7M=.446e6122-c301-4dd9-9704-b72606275f4c@github.com>
Message-ID: <2njZagvxZ9Zg1jZxmHodVDz3hoPQC8iKuHE4g78Oa-k=.9732f246-e4f1-46da-89c2-efd69e122096@github.com>

On Sat, 14 Oct 2023 03:21:52 GMT, himichael  wrote:

>>> my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8. is there a problem with my configuration ?
>> 
>> Hello @himichael,
>> 
>> Using your code snippet, please see the output below using the latest JDK and JDK 20 (which does not have AVX512 sort):
>> 
>> JDK 20 (without AVX512 sort): 
>> `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort `
>> 
>> elapse time -> **7501 ms**
>> 
>> ------------------------------
>> JDK 22 (with AVX512 sort)
>> `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort`
>> elapse time -> **1607 ms**
>> 
>> It shows 4.66x speedup.
>
>> > my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8. is there a problem with my configuration ?
>> 
>> Hello @himichael,
>> 
>> Using your code snippet, please see the output below using the latest JDK and JDK 20 (which does not have AVX512 sort):
>> 
>> JDK 20 (without AVX512 sort): `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort `
>> 
>> elapse time -> **7501 ms**
>> 
>> JDK 22 (with AVX512 sort) `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort` elapse time -> **1607 ms**
>> 
>> It shows 4.66x speedup.
> 
> Hello, @vamsi-parasa 
> I used the commands you provided, but nothing seems to have changed.   
> The test procedure as follow:   
> use JDK 8(without AVX512 sort)   
> 
> /data/soft/jdk1.8.0_371/bin/javac  JDKSort.java
> /data/soft/jdk1.8.0_371/bin/java  JDKSort
> 
> elapse time -> **15309 ms**   
>    
> use OpenJDK 22.19(with AVX512 sort)   
> 
> /data/soft/jdk-22/bin/javac JDKSort.java
> /data/soft/jdk-22/bin/java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort
> CompileCommand: CompileThresholdScaling java/util/DualPivotQuicksort.sort double CompileThresholdScaling = 0.000100
> 
> elapse time -> **11687 ms**
>    
> Not much seems to have changed.   
> 
> My JDK info:   
> OpenJDK 22.19:
> 
> /data/soft/jdk-22/bin/java -version
> openjdk version "22-ea" 2024-03-19
> OpenJDK Runtime Environment (build 22-ea+19-1460)
> OpenJDK 64-Bit Server VM (build 22-ea+19-1460, mixed mode, sharing)
> 
> 
> JDK 8:
> 
> /data/soft/jdk1.8.0_371/bin/java -version
> java version "1.8.0_371"
> Java(TM) SE Runtime Environment (build 1.8.0_371-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.371-b11, mixed mode)
> 
> 
> 
> I tested Intel's **x86-simd-sort**, my code as follow:
> ```c++
> #include 
> #include 
> #include 
> #include 
> #include "src/avx512-32bit-qsort.hpp"
> 
> int main() {
> 
>     // 100 million records
>     const int size = 100000000;
>     std::vector random_array(size);
> 
>     for (int i = 0; i < size; ++i) {
>         random_array[i] = rand();
>     }
> 
>     auto start_time = std::chrono::steady_clock::now();
> 
>     avx512_qsort(random_array.data(), size);
> 
>     auto end_time = std::chrono::steady_clock::now();
>     auto elapse_time = std::chrono::duration_cast(end_time - start_time)....

@himichael , could you check if the libsimdsort.so is being loaded by running the command below?
`java -Xlog:library  --version | grep libsimdsort`

Here is my output:
[0.021s][info][library] Loaded library **libsimdsort.so**, handle 0x00007fa3c801ad80

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1763280183

From duke at openjdk.org  Sun Oct 15 07:43:53 2023
From: duke at openjdk.org (himichael)
Date: Sun, 15 Oct 2023 07:43:53 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: <_MGkyOjyeyCIOE_HpYGCpzN3zN6bJEtaMGo_3T66e7M=.446e6122-c301-4dd9-9704-b72606275f4c@github.com>
References: 
 
 
 <3wco3meaBNwjfDWtVvkkoRfgG7-Wu1XZJTfJFduX5LE=.adbcd599-bcab-45a8-896f-cd2c65510352@github.com>
 
 
 <_MGkyOjyeyCIOE_HpYGCpzN3zN6bJEtaMGo_3T66e7M=.446e6122-c301-4dd9-9704-b72606275f4c@github.com>
Message-ID: 

On Sat, 14 Oct 2023 03:21:52 GMT, himichael  wrote:

>>> my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8. is there a problem with my configuration ?
>> 
>> Hello @himichael,
>> 
>> Using your code snippet, please see the output below using the latest JDK and JDK 20 (which does not have AVX512 sort):
>> 
>> JDK 20 (without AVX512 sort): 
>> `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort `
>> 
>> elapse time -> **7501 ms**
>> 
>> ------------------------------
>> JDK 22 (with AVX512 sort)
>> `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort`
>> elapse time -> **1607 ms**
>> 
>> It shows 4.66x speedup.
>
>> > my question is that this feature should improve performance several times, but it doesn't look like there's much difference between open jdk 22.19 and jdk 8. is there a problem with my configuration ?
>> 
>> Hello @himichael,
>> 
>> Using your code snippet, please see the output below using the latest JDK and JDK 20 (which does not have AVX512 sort):
>> 
>> JDK 20 (without AVX512 sort): `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort `
>> 
>> elapse time -> **7501 ms**
>> 
>> JDK 22 (with AVX512 sort) `java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort` elapse time -> **1607 ms**
>> 
>> It shows 4.66x speedup.
> 
> Hello, @vamsi-parasa 
> I used the commands you provided, but nothing seems to have changed.   
> The test procedure as follow:   
> use JDK 8(without AVX512 sort)   
> 
> /data/soft/jdk1.8.0_371/bin/javac  JDKSort.java
> /data/soft/jdk1.8.0_371/bin/java  JDKSort
> 
> elapse time -> **15309 ms**   
>    
> use OpenJDK 22.19(with AVX512 sort)   
> 
> /data/soft/jdk-22/bin/javac JDKSort.java
> /data/soft/jdk-22/bin/java -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001 -XX:-TieredCompilation JDKSort
> CompileCommand: CompileThresholdScaling java/util/DualPivotQuicksort.sort double CompileThresholdScaling = 0.000100
> 
> elapse time -> **11687 ms**
>    
> Not much seems to have changed.   
> 
> My JDK info:   
> OpenJDK 22.19:
> 
> /data/soft/jdk-22/bin/java -version
> openjdk version "22-ea" 2024-03-19
> OpenJDK Runtime Environment (build 22-ea+19-1460)
> OpenJDK 64-Bit Server VM (build 22-ea+19-1460, mixed mode, sharing)
> 
> 
> JDK 8:
> 
> /data/soft/jdk1.8.0_371/bin/java -version
> java version "1.8.0_371"
> Java(TM) SE Runtime Environment (build 1.8.0_371-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.371-b11, mixed mode)
> 
> 
> 
> I tested Intel's **x86-simd-sort**, my code as follow:
> ```c++
> #include 
> #include 
> #include 
> #include 
> #include "src/avx512-32bit-qsort.hpp"
> 
> int main() {
> 
>     // 100 million records
>     const int size = 100000000;
>     std::vector random_array(size);
> 
>     for (int i = 0; i < size; ++i) {
>         random_array[i] = rand();
>     }
> 
>     auto start_time = std::chrono::steady_clock::now();
> 
>     avx512_qsort(random_array.data(), size);
> 
>     auto end_time = std::chrono::steady_clock::now();
>     auto elapse_time = std::chrono::duration_cast(end_time - start_time)....

> @himichael , could you check if the libsimdsort.so is being loaded by running the command below? `java -Xlog:library --version | grep libsimdsort`
> 
> Here is my output: [0.021s][info][library] Loaded library **libsimdsort.so**, handle 0x00007fa3c801ad80

Hello, @vamsi-parasa,  
   
I see why, I run command ```/data/soft/jdk-22/bin/java  -Xlog:library -version```  
results as follows:

[0.071s][info][library] Loaded library libjsvml.so, handle 0x00007f3a5c0223e0
openjdk version "22-ea" 2024-03-19
OpenJDK Runtime Environment (build 22-ea+19-1460)
OpenJDK 64-Bit Server VM (build 22-ea+19-1460, mixed mode, sharing)

There is no information about ```libsimdsort.so```  
   
   
run ```/data/soft/jdk-22/bin/java  -Xlog:library``` the results as follows:   

[0.044s][info][library] Loaded library libjsvml.so, handle 0x00007f00b40223e0
[0.067s][info][library] Failed to find JNI_OnLoad_nio in library with handle 0x00007f016a4f6150
[0.068s][info][library] Loaded library /data/soft/jdk-22/lib/libnio.so, handle 0x00007f0160196da0
[0.068s][info][library] Found JNI_OnLoad in library with handle 0x00007f0160196da0
[0.069s][info][library] Found Java_sun_nio_fs_UnixNativeDispatcher_init in library with handle 0x00007f0160196da0
[0.069s][info][library] Found Java_sun_nio_fs_UnixNativeDispatcher_getcwd in library with handle 0x00007f0160196da0
[0.069s][info][library] Failed to find JNI_OnLoad_jimage in library with handle 0x00007f016a4f6150
[0.069s][info][library] Loaded library /data/soft/jdk-22/lib/libjimage.so, handle 0x00007f0160005450
[0.069s][info][library] Failed to find JNI_OnLoad in library with handle 0x00007f0160005450
[0.069s][info][library] Failed to find Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap in library with handle 0x00007f0160196da0
[0.069s][info][library] Found Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap in library with handle 0x00007f0160005450

It shows some bad failures, but it doesn't seem to have anything to do with libsimdsort.   
I am not using a physical machine, I am using a virtual machine, this virtual machine supports the AVX512 instruction set.   
How do I open libsimdsort ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1763307754

From mchhipa at openjdk.org  Sun Oct 15 16:06:17 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Sun, 15 Oct 2023 16:06:17 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed
 [v10]
In-Reply-To: 
References: 
Message-ID: 

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request incrementally with two additional commits since the last revision:

 - Removed commented code.
 - Use of HexFormatter clas instead of Formatter.
   Addition of copyright section in autogenerated source file.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/5326282f..b292c9d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=08-09

  Stats: 82 lines in 3 files changed: 36 ins; 14 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From mchhipa at openjdk.org  Sun Oct 15 16:36:33 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Sun, 15 Oct 2023 16:36:33 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed
 [v11]
In-Reply-To: 
References: 
Message-ID: 

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Corrected use of whitespace in text block.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/b292c9d0..2512e026

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From redestad at openjdk.org  Sun Oct 15 17:57:28 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 15 Oct 2023 17:57:28 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

I don't have anything in principle against moving `stringSize` to `j.u.DecimalDigits` as it doesn't leak information about internal `String` encoding, but we need to be very careful about exposing implementation details of `StringLatin1/StringUTF16` and leaning on such details, even internally, since it increase the risk for subtle bugs and increases maintenance overheads. The bar for exposing internals via JLA or even moving them to `jdk.internal.util` classes needs to be very high.

I'd say go with what you have now:  once we enable compiling `java.math.BigDecimals` so that string concatenation uses `StringConcatFactory` then peak performance should improve. The only reasonable alternative in my mind is to revert changes for this branch entirely (reinstating the `StringBuilderHelper` etc) and revisit this once we have a solution that ensures both better performance and simpler code.

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1763459786

From duke at openjdk.org  Sun Oct 15 22:35:57 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 15 Oct 2023 22:35:57 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

Can I use StringConcatHelper.prepend? as follows:


  static final class ConcatHelper {
        static final MethodHandle STRING_PREPEND =
                JLA.stringConcatHelper("prepend",
                        MethodType.methodType(long.class, long.class, byte[].class, long.class));
        static String scale2(long intCompact) {
            long highInt = intCompact / 100;
            int highIntSize = JLA.stringSize(highInt);
            byte[] buf = new byte[highIntSize + 3];
            try {
                long coder = (long) ConcatHelper.STRING_PREPEND.invokeExact((long) highIntSize, buf, highInt);
                buf[highIntSize] = '.';
                short pair = DecimalDigits.digitPair((int)(Math.abs(intCompact) % 100));
                buf[highIntSize + 1] = (byte)(pair & 0xff);
                buf[highIntSize + 2] = (byte)(pair >> 8);
                return JLA.newStringNoRepl(buf, StandardCharsets.ISO_8859_1);
            } catch (Throwable e) {
                throw new AssertionError(e);
            }
        }
    }

    private String layoutChars(boolean sci) {
        int scale = this.scale;
        long intCompact = this.intCompact;
        if (scale == 0)                      // zero scale is trivial
            return unscaledString();
        if (scale == 2  && intCompact != INFLATED) {
            // currency fast path
            return ConcatHelper.scale2(intCompact);
        }
        // ...
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1763523085

From egahlin at openjdk.org  Sun Oct 15 22:38:54 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 15 Oct 2023 22:38:54 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
Message-ID: 

Hi,

Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base.

To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. 

Testing: tier1-3 + jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/16195/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16195&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318124
  Stats: 1174 lines in 12 files changed: 427 ins; 394 del; 353 mod
  Patch: https://git.openjdk.org/jdk/pull/16195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16195/head:pull/16195

PR: https://git.openjdk.org/jdk/pull/16195

From liach at openjdk.org  Mon Oct 16 00:04:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Oct 2023 00:04:05 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
In-Reply-To: 
References: 
Message-ID: 

On Sun, 15 Oct 2023 20:20:48 GMT, Erik Gahlin  wrote:

> Hi,
> 
> Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base.
> 
> To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. 
> 
> Testing: tier1-3 + jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/EventClassBuilder.java line 73:

> 71:         byte[] bytes = Classfile.of().build(ClassDesc.of(fullClassName), cb -> build(cb));
> 72:         try {
> 73:             String name = "/Users/egahlin/DynamicEvent" + (idCounter.longValue() - 1);

You probably wish to use `Bytecode.log` instead.

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 204:

> 202:         String typeDescriptor = classDesc.descriptorString();
> 203:         for (ClassElement ce : classModel.elements()) {
> 204:             if (ce instanceof RuntimeVisibleAnnotationsAttribute rvaa) {

You can use `classModel.findAttribute(Attributes.RUNTIME_VISIBLE_ANNOTATIONS)` instead of looping.

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 227:

> 225:         for (MethodModel m : classModel.methods()) {
> 226:             for (MethodElement me : m.elements()) {
> 227:                 if (me instanceof RuntimeVisibleAnnotationsAttribute rvaa) {

Same remark, `m.findAttribute(Attributes.RUNTIME_VISIBLE_ANNOTATIONS)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1359971991
PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1359976477
PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1359976987

From egahlin at openjdk.org  Mon Oct 16 00:50:51 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Oct 2023 00:50:51 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
In-Reply-To: 
References: 
 
Message-ID: <5-fsuqVJ0QNfYYdvc2wWkSGrJaqwT2QkAI-tbgN480M=.56dbd977-507a-4236-80ea-572990491a5e@github.com>

On Sun, 15 Oct 2023 23:34:01 GMT, Chen Liang  wrote:

>> Hi,
>> 
>> Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base.
>> 
>> To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. 
>> 
>> Testing: tier1-3 + jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventClassBuilder.java line 73:
> 
>> 71:         byte[] bytes = Classfile.of().build(ClassDesc.of(fullClassName), cb -> build(cb));
>> 72:         try {
>> 73:             String name = "/Users/egahlin/DynamicEvent" + (idCounter.longValue() - 1);
> 
> You probably wish to use `Bytecode.log` instead.

Yes, looks like I missed some changes. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1359996178

From dholmes at openjdk.org  Mon Oct 16 01:26:54 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Oct 2023 01:26:54 GMT
Subject: RFR: 8318126: Refresh manpages
Message-ID: 

The open nroff manpage files are out of sync with their closed markdown sources and need to be refreshed.

The changes to apply are coming from:

- [JDK-8288158](https://bugs.openjdk.org/browse/JDK-8288158): Add an anchor to each subcommand option on jfr html page
- [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
- [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
- [JDK-8308662](https://bugs.openjdk.org/browse/JDK-8308662): Update the "java" tool specification for CompileOnly
- [JDK-8317565](https://bugs.openjdk.org/browse/JDK-8317565): Update Manpage for obsoletion of UseSHM
- [JDK-8310460](https://bugs.openjdk.org/browse/JDK-8310460): Remove jdeps -profile option

There are also some simple line break changes, likely due to using different versions of the pandoc tool.

Thanks

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

Commit messages:
 - 8318126: Refresh manpages

Changes: https://git.openjdk.org/jdk/pull/16196/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16196&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318126
  Stats: 115 lines in 4 files changed: 27 ins; 64 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16196/head:pull/16196

PR: https://git.openjdk.org/jdk/pull/16196

From duke at openjdk.org  Mon Oct 16 02:15:32 2023
From: duke at openjdk.org (xpbob)
Date: Mon, 16 Oct 2023 02:15:32 GMT
Subject: Withdrawn: 8318058: Notify the jvm when the direct memory is oom
In-Reply-To: 
References: 
Message-ID: <0FMEIyZwzX0DoJNG8hnJpN0ey6Ox_SjPLK0gJ1COJ3A=.21bbcd0a-ded3-4a66-b13e-c190f094b3ef@github.com>

On Fri, 13 Oct 2023 03:23:04 GMT, xpbob  wrote:

> Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
> 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
> 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/16176

From duke at openjdk.org  Mon Oct 16 03:22:04 2023
From: duke at openjdk.org (xpbob)
Date: Mon, 16 Oct 2023 03:22:04 GMT
Subject: RFR: 8318058: Notify the jvm when the direct memory is oom
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 05:26:37 GMT, Thomas Stuefe  wrote:

>> Big data processes often experience situations where the direct memory oom process is alive but not serving properly. If the direct memory is oom, code can notify the jvm. Can bring the following benefits:
>> 1. Analysis of direct memory Java. Nio. DirectByteBuffer need heapdumps reference relations. Can be used directly HeapDumpOnOutOfMemoryError.
>> 2. In container environment, ExitOnOutOfMemoryError can be used to let the process that cannot provide services exit, so that the container can quickly pull up a new pod
>
> Undoubtedly useful, but there have been many discussions in the past about what does and does not constitute an OOM error, and IIRC, the stance of Oracle devs was "only if it is in java heap". Hence the missing OOM error when we cannot create threads, for instance.

@tstuefe @AlanBateman 
Thanks for for sharing this information,
We look forward to other solutions to this problem in the future

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

PR Comment: https://git.openjdk.org/jdk/pull/16176#issuecomment-1763663559

From egahlin at openjdk.org  Mon Oct 16 05:07:42 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Oct 2023 05:07:42 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base.
> 
> To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. 
> 
> Testing: tier1-3 + jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16195/files
  - new: https://git.openjdk.org/jdk/pull/16195/files/cac2e347..ba96d273

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16195&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16195&range=00-01

  Stats: 31 lines in 3 files changed: 6 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16195/head:pull/16195

PR: https://git.openjdk.org/jdk/pull/16195

From egahlin at openjdk.org  Mon Oct 16 05:07:44 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Oct 2023 05:07:44 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 15 Oct 2023 23:45:05 GMT, Chen Liang  wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 204:
> 
>> 202:         String typeDescriptor = classDesc.descriptorString();
>> 203:         for (ClassElement ce : classModel.elements()) {
>> 204:             if (ce instanceof RuntimeVisibleAnnotationsAttribute rvaa) {
> 
> You can use `classModel.findAttribute(Attributes.RUNTIME_VISIBLE_ANNOTATIONS)` instead of looping.

I could not get it to work with findAttribute. No annotations were found.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1360107669

From liach at openjdk.org  Mon Oct 16 06:03:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Oct 2023 06:03:58 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <4AgWvA47z2onAyBmshEwEkIOsIKXFZggZ5pso_Qcy7I=.c9466e61-1dfe-48a9-89ca-6259b391db12@github.com>

On Mon, 16 Oct 2023 05:02:01 GMT, Erik Gahlin  wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 204:
>> 
>>> 202:         String typeDescriptor = classDesc.descriptorString();
>>> 203:         for (ClassElement ce : classModel.elements()) {
>>> 204:             if (ce instanceof RuntimeVisibleAnnotationsAttribute rvaa) {
>> 
>> You can use `classModel.findAttribute(Attributes.RUNTIME_VISIBLE_ANNOTATIONS)` instead of looping.
>
> I could not get it to work with findAttribute. No annotations were found.

The existing code will silently finish the loop no-op and return `null` if no RVAA is present. So if `findAttribute` returns `Optional.empty()`, you should just return `null` to match the old behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1360143716

From liach at openjdk.org  Mon Oct 16 06:04:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Oct 2023 06:04:01 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 05:07:42 GMT, Erik Gahlin  wrote:

>> Hi,
>> 
>> Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base.
>> 
>> To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. 
>> 
>> Testing: tier1-3 + jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:

> 254:                                 if (mtd.parameterList().size() == 1) {
> 255:                                     ClassDesc type = mtd.parameterList().getFirst();
> 256:                                     if (type.isClassOrInterface()) {

In the original, ASM-based code, there was no such check to ensure the type is non-primitive or non-array. Is this intended?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1360150828

From alanb at openjdk.org  Mon Oct 16 06:05:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 06:05:36 GMT
Subject: RFR: 8318126: Refresh manpages
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 01:18:52 GMT, David Holmes  wrote:

> The open nroff manpage files are out of sync with their closed markdown sources and need to be refreshed.
> 
> The changes to apply are coming from:
> 
> - [JDK-8288158](https://bugs.openjdk.org/browse/JDK-8288158): Add an anchor to each subcommand option on jfr html page
> - [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> - [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> - [JDK-8308662](https://bugs.openjdk.org/browse/JDK-8308662): Update the "java" tool specification for CompileOnly
> - [JDK-8317565](https://bugs.openjdk.org/browse/JDK-8317565): Update Manpage for obsoletion of UseSHM
> - [JDK-8310460](https://bugs.openjdk.org/browse/JDK-8310460): Remove jdeps -profile option
> 
> There are also some simple line break changes, likely due to using different versions of the pandoc tool.
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16196#pullrequestreview-1679166064

From egahlin at openjdk.org  Mon Oct 16 06:11:58 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Oct 2023 06:11:58 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v2]
In-Reply-To: <4AgWvA47z2onAyBmshEwEkIOsIKXFZggZ5pso_Qcy7I=.c9466e61-1dfe-48a9-89ca-6259b391db12@github.com>
References: 
 
 
 <4AgWvA47z2onAyBmshEwEkIOsIKXFZggZ5pso_Qcy7I=.c9466e61-1dfe-48a9-89ca-6259b391db12@github.com>
Message-ID: 

On Mon, 16 Oct 2023 05:56:00 GMT, Chen Liang  wrote:

>> I could not get it to work with findAttribute. No annotations were found.
>
> The existing code will silently finish the loop no-op and return `null` if no RVAA is present. So if `findAttribute` returns `Optional.empty()`, you should just return `null` to match the old behavior.

I added logging, and from what I could see, findAttribute always returned Optional.empty().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1360154968

From egahlin at openjdk.org  Mon Oct 16 06:12:02 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Oct 2023 06:12:02 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 16 Oct 2023 06:01:01 GMT, Chen Liang  wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:
> 
>> 254:                                 if (mtd.parameterList().size() == 1) {
>> 255:                                     ClassDesc type = mtd.parameterList().getFirst();
>> 256:                                     if (type.isClassOrInterface()) {
> 
> In the original, ASM-based code, there was no such check to ensure the type is non-primitive or non-array. Is this intended?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1360155805

From aturbanov at openjdk.org  Mon Oct 16 06:27:51 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 16 Oct 2023 06:27:51 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 05:07:42 GMT, Erik Gahlin  wrote:

>> Hi,
>> 
>> Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base.
>> 
>> To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. 
>> 
>> Testing: tier1-3 + jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates

src/jdk.jfr/share/classes/jdk/jfr/internal/util/Bytecode.java line 45:

> 43: public final class Bytecode {
> 44: 
> 45:     private final static ClassDesc CD_Thread = classDesc(Thread.class);

Use blessed modifiers order
Suggestion:

    private static final ClassDesc CD_Thread = classDesc(Thread.class);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1360166922

From jpai at openjdk.org  Mon Oct 16 07:24:28 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Oct 2023 07:24:28 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 12:18:41 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor test edits and comment updates

test/jdk/java/util/zip/ZipFile/ZipSourceCache.java line 59:

> 57:     @AfterAll
> 58:     public static void cleanup() throws IOException {
> 59:         Files.deleteIfExists(Path.of(ZIPENTRY_NAME));

Hello Sean, this looks like a typo to me. I think it should have been `ZIPFILE_NAME` instead of `ZIPENTRY_NAME`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1360215640

From fyang at openjdk.org  Mon Oct 16 07:40:13 2023
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 16 Oct 2023 07:40:13 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 15:36:56 GMT, Ilya Gavrilin  wrote:

> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
> 
> Tests:
> Performance tests on t-head board:
> With intrinsics:
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
> 
> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
> 
> Regression tests: tier1, hotspot:tier2 on risc-v board.
> 
> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
> 
> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> index 6cd1353907e..0bee25366bf 100644
> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>  
>      @Benchmark
>      public double  copySignDouble() {
> -        return  Math.copySign(double81, doubleNegative12);
> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>      }
>  
>      @Benchmark
>      public float  copySignFloat() {
> -        return  Math.copySign(floatNegative99, float1);
> +        return  Math.copySign(floatNegative99, float1) + Math.copySign(eFloat, float1) + Math.copySign...

Some comments after a brief look.

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1659:

> 1657: // on input we have NaN or +/-0.0 value we should return it,
> 1658: // otherwise return +/- 1.0 using sign of input.
> 1659: // tmp1 - used to store result of fclass operation,

Seems to me that scratch register `t0` could be used in this function in order to save use of `tmp1`.

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1661:

> 1659: // tmp1 - used to store result of fclass operation,
> 1660: // one - gives us a floating-point 1.0 (got from matching rule)
> 1661: // bool single_precision - specififes single or double precision operations will be used.

Suggestion: s/bool single_precision - specififes/bool is_double - specifies/

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1663:

> 1661: // bool single_precision - specififes single or double precision operations will be used.
> 1662: void C2_MacroAssembler::signum_fp(FloatRegister dst, FloatRegister src, FloatRegister one, Register tmp1, bool is_double) {
> 1663:   assert_different_registers(dst, src, one);

This constraint could be relaxed if we use scratch register `t0` here instead of `tmp`.

src/hotspot/cpu/riscv/riscv.ad line 7511:

> 7509: // Copysign and signum intrinsics
> 7510: 
> 7511: instruct copySignD_reg(fRegD dst, fRegD src1, fRegD src2, immD0 zero) %{

A more simpler `immD zero` will do here which is similar with the x86 counterpart.

src/hotspot/cpu/riscv/riscv.ad line 7513:

> 7511: instruct copySignD_reg(fRegD dst, fRegD src1, fRegD src2, immD0 zero) %{
> 7512:   match(Set dst (CopySignD src1 (Binary src2 zero)));
> 7513:   effect(TEMP_DEF dst, USE src1, USE src2);

Unnecessary effect.

src/hotspot/cpu/riscv/riscv.ad line 7526:

> 7524: instruct copySignF_reg(fRegF dst, fRegF src1, fRegF src2) %{
> 7525:   match(Set dst (CopySignF src1 src2));
> 7526:   effect(TEMP_DEF dst, USE src1, USE src2);

Unnecessary effect.

src/hotspot/cpu/riscv/riscv.ad line 7537:

> 7535: %}
> 7536: 
> 7537: instruct signumD_reg(fRegD dst, fRegD src, fRegD zero, fRegD one, iRegINoSp tmp1) %{

Use `immD zero` instread, which will help avoid reserving one FP register here.

src/hotspot/cpu/riscv/riscv.ad line 7539:

> 7537: instruct signumD_reg(fRegD dst, fRegD src, fRegD zero, fRegD one, iRegINoSp tmp1) %{
> 7538:   match(Set dst (SignumD src (Binary zero one)));
> 7539:   effect(TEMP_DEF dst, USE src, USE one, TEMP tmp1);

Unnecessary effect if changed to use `t0` instead of `tmp1` in `signum_fp`.

src/hotspot/cpu/riscv/riscv.ad line 7548:

> 7546: %}
> 7547: 
> 7548: instruct signumF_reg(fRegF dst, fRegF src, fRegF zero, fRegF one, iRegINoSp tmp1) %{

Use `immF zero` instread, which will help avoid reserving one FP register here.

src/hotspot/cpu/riscv/riscv.ad line 7550:

> 7548: instruct signumF_reg(fRegF dst, fRegF src, fRegF zero, fRegF one, iRegINoSp tmp1) %{
> 7549:   match(Set dst (SignumF src (Binary zero one)));
> 7550:   effect(TEMP_DEF dst, USE src, USE one, TEMP tmp1);

Unnecessary effect if changed to use `t0` instead of `tmp1` in `signum_fp`.

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

PR Review: https://git.openjdk.org/jdk/pull/16186#pullrequestreview-1679272664
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360216914
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360215721
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360219620
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360221019
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360230241
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360230310
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360222911
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360231462
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360223205
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1360231642

From jpai at openjdk.org  Mon Oct 16 07:49:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Oct 2023 07:49:52 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 12:18:41 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor test edits and comment updates

I had a look at the linked JBS and the new jtreg test case in this PR. Is my understanding correct that the issue that we are trying to solve here is the case where the cache would end up having 2 separate entries for the same jar file, if one `JarFile` was constructed using an absolute path and the other `JarFile` (for the same underlying file on the filesystem) was constructed using a relative path?

The mention of fixing hashCode() makes me wonder if there is/was some other issue that was triggered which lead to creation of that JBS issue.

Coming to the proposed implementation in this PR, I see that we first rely on `BasicFileAttributes.fileKey()` and if it is available for a given `File` instance, we store that `File` instance as a component of the `Key`. Looking at the javadoc of `BasicFileAttributes.fileKey()` it states:


* Returns an object that uniquely identifies the given file, or {@code
* null} if a file key is not available. On some platforms or file systems
* it is possible to use an identifier, or a combination of identifiers to
* uniquely identify a file. Such identifiers are important for operations
* such as file tree traversal in file systems that support symbolic links or file systems
* that allow a file to be an entry in more than one directory. On UNIX file
* systems, for example, the device ID and inode are
* commonly used for such purposes.

It's unclear to me (and I haven't yet read up on inode management in Unix) if 2 different symbolic links pointing to the same target (jar) file on the filesystem would have 2 different/unique `fileKey()`. If they do, then do you think that even with the current proposed solution of using `fileKey()`, we would still end up with 2 different entries in this cache, each with a different `Key`? Would that then bring us back to the original issue?

As for the use of `File.getCanonicalFile()` in the absence of a `fileKey()`, there used to be performance considerations with the use of `File.getCanonicalFile()` (and `File.getCanonicalPath()`) to the extent that there used to be a cache involved. Recent versions of Java have removed that cache because it was no longer necessary as detailed in https://bugs.openjdk.org/browse/JDK-8301001. I don't have historical knowledge behind the motivation of that cache (JDK-8301001 does provide some necessary history), however JDK-8301001 also says that one of the reasons why the cache is no longer needed is because:

> The work in JDK 9 to remove canonicalization from FilePermission (JDK-8164705) mostly eliminated the need for this caching.

Would introducing this `File.getCanonicalFile()` in this `JarFile` area now reintroduce performance considerations (for startup?) on filesystems that don't return a `fileKey()`? I see that the implementation of `File.getCanonicalFile()` now ends up being a native call.

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

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1763912405

From alanb at openjdk.org  Mon Oct 16 07:56:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 07:56:50 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 12:18:41 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor test edits and comment updates

src/java.base/share/classes/java/util/zip/ZipFile.java line 1423:

> 1421:                                 (PrivilegedExceptionAction) file::getCanonicalFile);
> 1422:                     } catch (PrivilegedActionException pae) {
> 1423:                         throw new IOException(pae.getException());

The exception handling isn't right, you should be re-throwing pae.getException when it's an IOException, this should do what you want

        PrivilegedExceptionAction pa = file::getCanonicalFile;
        try {
            return AccessController.doPrivileged(pa);
        } catch (PrivilegedActionException pae) {
            Throwable cause = pae.getCause();
            if (cause instanceof IOException ioe) {
                throw ioe;
            } else {
                throw new IOException(cause);
            }
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1360264749

From alanb at openjdk.org  Mon Oct 16 07:59:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 07:59:52 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 13 Oct 2023 12:18:41 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor test edits and comment updates

src/java.base/share/classes/java/util/zip/ZipFile.java line 1430:

> 1428:             public int hashCode() {
> 1429:                 long t = utf8 ? 0 : Long.MAX_VALUE;
> 1430:                 t += attrs.lastModifiedTime().toMillis();

ZipFile cannot tolerate a zip file being changed while in use. I realise you don't want to change this part of the code but I think it is desperately needs a comment in both hashCode and equals to explain why the last modified time is included.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1360269216

From mli at openjdk.org  Mon Oct 16 08:08:58 2023
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 16 Oct 2023 08:08:58 GMT
Subject: RFR: 8318126: Refresh manpages
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 01:18:52 GMT, David Holmes  wrote:

> The open nroff manpage files are out of sync with their closed markdown sources and need to be refreshed.
> 
> The changes to apply are coming from:
> 
> - [JDK-8288158](https://bugs.openjdk.org/browse/JDK-8288158): Add an anchor to each subcommand option on jfr html page
> - [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> - [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> - [JDK-8308662](https://bugs.openjdk.org/browse/JDK-8308662): Update the "java" tool specification for CompileOnly
> - [JDK-8317565](https://bugs.openjdk.org/browse/JDK-8317565): Update Manpage for obsoletion of UseSHM
> - [JDK-8310460](https://bugs.openjdk.org/browse/JDK-8310460): Remove jdeps -profile option
> 
> There are also some simple line break changes, likely due to using different versions of the pandoc tool.
> 
> Thanks

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16196#pullrequestreview-1679368261

From redestad at openjdk.org  Mon Oct 16 08:41:58 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Oct 2023 08:41:58 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

Might as well use `StringConcatFactory.makeConcatWithConstants` as per my suggestion above, which bootstraps a concatenation expression that should be about as optimal as can be here? While there's some ceremony to it it's all public API, and we can simplify to `return "" + ...` when/if we manage to set up the build system to compile parts of java.base without `-XDstringConcat=inline`

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1763992162

From duke at openjdk.org  Mon Oct 16 11:00:51 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 16 Oct 2023 11:00:51 GMT
Subject: RFR: 8317742: ISO Starndard Date Format implementation consistency
 on DateTimeFormatter and String.format [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 12 Oct 2023 06:01:41 GMT, Shaojin Wen  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No longer localize printed numbers
>
> # Summary
> Keep the behavior of String.format('%tF') when printing LocalDate consistent with the behavior of DateTimeFormatter.ISO_LOCAL_DATE.
> 
> 
> # Problem
> 1. When using String.format('%tF', localDate), use get(ChronoField.YEAR_OF_ERA). When the value range is not [0,9999], the behavior is inconsistent with DateTimeFormatter.ISO_LOCAL_DATE.format.
> 2. When String.format('%tF', localDate), Locale will be processed, which is inconsistent with the standard.
> 
> * the year value range [-?, -1] changes:
> ``` java
> String.format("%tF", LocalDate.of(-10000, 1, 1))
> // String.format 10001-01-01
> // DateTimeFormatter  -99999-01-01
> 
> 
> * the year value range [10000, +?] changes:
> 
> String.format("%tF", LocalDate.of(10000, 1, 1)):
> // String.format 10000-01-01
> // DateTimeFormatter.format  +10000-01-01
> And the "%tF" format no longer handles Locale when printing numbers.
> 
> 
> 
> Locale.setDefault(
>         Locale.forLanguageTag("th-TH-u-nu-thai"));
> String.format("%tF", LocalDate.of(2001, 1, 1));
> // String.format ????-??-??
> // DateTimeFormatter.ISO_LOCAL_DATE.format 2001-01-01
> 
> 
> # Solution
> 1. When String.format('%tF', localDate) uses ChronoField.YEAR instead of ChronoField.YEAR_OF_ERA, when year > 9999, the prefix is added with '+'
> 2. And don't use Locale to print numbers.
> 
> 
> # Specification
> * [-?, -1000]
> 
> String.format("%tF", LocalDate.of(-10000, 1, 1))
> // -10000-01-01
> 
> 
> The year value range [-999, -1], padded to 4 digits
> 
> String.format("%tF", LocalDate.of(-1, 1, 1))
> // -0001-01-01
> 
> 
> 
> The year value range [1, 9999], padded to 4 digits
> 
> String.format("%tF", LocalDate.of(1, 1, 1))
> // 0001-01-01
> 
> 
> * The year value range [10000, -?], prefix prints '+'
> 
> String.format("%tF", LocalDate.of(10000, 1, 1))
> // +10000-01-01
> 
> 
> #  Risk
> 1. When String.format('%tF') processes LocalDate/ZonedDateTime/OffsetDateTime, if the value range of year is not in [0-9999], the output will be different from before.
> 2. When the Locale of String.format('%tF') is "th-TH-u-nu-thai", the printed result is different from before.

@wenshao I fixed the spelling of "standard" in the JBS issue and CSR. Can you update the PR title as well? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1764222545

From msheppar at openjdk.org  Mon Oct 16 11:16:52 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 16 Oct 2023 11:16:52 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 13:53:58 GMT, Matthew Donovan  wrote:

>> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.
>
> Matthew Donovan has updated the pull request with a new target base 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 socket-params
>  - Merge branch 'master' into socket-params
>  - added javadocs to new methods
>  - 8303525: Refactor/cleanup open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 77:

> 75: 
> 76:     public void testRmiCommunication(RMIServerSocketFactory serverFactory) throws Exception {
> 77:             Hello stub = (Hello)UnicastRemoteObject.exportObject(new HelloImpl(),

by not retaining an explicit reference to the test rmi server, you are exposing it to potentially being GCed during the test execution  and potemntially prior to client invocation... this might sound fanciful but  this has been observed in a few scenarios due to the GC  changes ... althought it doesn't seem to have been an issue, the structure of the test appears to be inherently racy, with the potential for the client invocation to get ahead of the client with the rmi server launching bacground threads.
Any caution on not retaining a sever reference and GC interference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1360500322

From egahlin at openjdk.org  Mon Oct 16 11:28:36 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Oct 2023 11:28:36 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base.
> 
> To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. 
> 
> Testing: tier1-3 + jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Blessed order

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16195/files
  - new: https://git.openjdk.org/jdk/pull/16195/files/ba96d273..a0278e7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16195&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16195&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16195/head:pull/16195

PR: https://git.openjdk.org/jdk/pull/16195

From duke at openjdk.org  Mon Oct 16 11:55:50 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 11:55:50 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

The performance of using StringConcatFactory.makeConcatWithConstants is sometimes fast and sometimes slow:


# Run progress: 0.00% complete, ETA 00:00:30
# Fork: 1 of 3
# Warmup Iteration   1: 19.816 ns/op
# Warmup Iteration   2: 17.289 ns/op
# Warmup Iteration   3: 17.653 ns/op
# Warmup Iteration   4: 17.703 ns/op
# Warmup Iteration   5: 17.698 ns/op
Iteration   1: 17.655 ns/op
Iteration   2: 17.564 ns/op
Iteration   3: 17.628 ns/op
Iteration   4: 17.760 ns/op
Iteration   5: 17.679 ns/op

# Run progress: 33.33% complete, ETA 00:00:20
# Fork: 2 of 3
# Warmup Iteration   1: 13.430 ns/op
# Warmup Iteration   2: 12.064 ns/op
# Warmup Iteration   3: 12.366 ns/op
# Warmup Iteration   4: 12.384 ns/op
# Warmup Iteration   5: 12.380 ns/op
Iteration   1: 12.370 ns/op
Iteration   2: 12.346 ns/op
Iteration   3: 12.395 ns/op
Iteration   4: 12.377 ns/op
Iteration   5: 12.351 ns/op

# Run progress: 66.67% complete, ETA 00:00:10
# Fork: 3 of 3
# Warmup Iteration   1: 19.125 ns/op
# Warmup Iteration   2: 17.398 ns/op
# Warmup Iteration   3: 17.801 ns/op
# Warmup Iteration   4: 17.702 ns/op
# Warmup Iteration   5: 17.766 ns/op
Iteration   1: 17.748 ns/op
Iteration   2: 17.804 ns/op
Iteration   3: 17.681 ns/op
Iteration   4: 17.673 ns/op
Iteration   5: 17.624 ns/op


It was run on a MacBook M1 Max. There were three iterations. The first time was slow, the second time was fast, and the third time was slow again.

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1764305769

From msheppar at openjdk.org  Mon Oct 16 12:12:52 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 16 Oct 2023 12:12:52 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 13:53:58 GMT, Matthew Donovan  wrote:

>> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.
>
> Matthew Donovan has updated the pull request with a new target base 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 socket-params
>  - Merge branch 'master' into socket-params
>  - added javadocs to new methods
>  - 8303525: Refactor/cleanup open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java

the test method testServerFactory could be viewed as a misnomer, so refactor rename testSslServerSocketFactory would seem to be more appropriate, while the serverFactory parameter name to testRmiCommunication could likewise be renamed to sslServerSocketFactory (or at least serverSocketFactory).

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

PR Comment: https://git.openjdk.org/jdk/pull/14932#issuecomment-1764338318

From redestad at openjdk.org  Mon Oct 16 12:27:54 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Oct 2023 12:27:54 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

I've seen this happen, too. Possibly a compiler bug or maybe an issue with the benchmark: Can you try changing the benchmark to produce a random distribution of values for the two digits, and not hardcode all values to end with `".55"`? This might be causing the JIT to speculate a bit too optimistically...

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1764362489

From duke at openjdk.org  Mon Oct 16 12:56:51 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 12:56:51 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

public class BigDecimals {
    public void setup() {
        for (int i = 0; i < TEST_SIZE; i++) {
            smallArray[i] = new BigDecimal("" + ((long) value / 1000) + ".5" + (i % 10));
        }
    }
}

I changed it, but it's still sometimes fast and sometimes slow.  But using StringConcatHelper.prepend is faster every time 

* StringConcatFactory.makeConcatWithConstants  branch : https://github.com/wenshao/jdk/tree/optim_decimal_to_string_x1_mcwc 
* StringConcatHelper.prepend  branch : https://github.com/wenshao/jdk/tree/optim_decimal_to_string_x1_test

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1764422223

From redestad at openjdk.org  Mon Oct 16 13:18:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Oct 2023 13:18:42 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: <7K0ag3HT5x-Uap_QvewAqCvjmZpwkBYQh8ORxGpcKhM=.a76d57c0-5fa1-485a-943c-5281c2e5f1d5@github.com>

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

I'd say go with the `makeConcatWithConstants` branch and file a follow-up to determine why it's intermittently slower and try to fix that. Chances are this is a fluke, or it's a symptom of an issue that would be good to analyze more in-depth. We shouldn't pick an implementation that is worse maintenance-wise just because it currently wins over cleaner, more idiomatic code but view that as a call to arms to improve the idiomatic case.

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1764465071

From duke at openjdk.org  Mon Oct 16 13:18:14 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 13:18:14 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v13]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 <9PZeY6qD_y8-v4wSS5UgohDHFz8kaol2pMdg8gR9Nbo=.4145a0f3-fa09-456c-804c-5f82c8d1a50e@github.com>
 
Message-ID: 

On Thu, 28 Sep 2023 15:01:25 GMT, Raffaello Giulietti  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor according to rgiulietti's suggestion and add testcases
>
> Meaningful external reviews take a _lot_ of engineering time on such a popular platform as the JDK.
> They make sense only on somehow stable code, otherwise they are a waste of human resources.
> 
> So sure, take your time to stabilize your code, make your tests, but please refrain from keep on changing too much once you publish a PR. If reviewers have to face continuous changes, they might become uninterested in reviewing.

@rgiulietti can you help me continue to review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1764464777

From liach at openjdk.org  Mon Oct 16 13:43:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Oct 2023 13:43:12 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

How does a `long, int` recipe compare to the `long, char, char` recipe for concat?

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1764507886

From sgehwolf at openjdk.org  Mon Oct 16 13:45:35 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 16 Oct 2023 13:45:35 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.jmod        jdk.unsupported...

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

 - Improve error message of run-image recursive link
 - Use a single option --unlock-run-image for single hop and warnings
 - JmodLessArchive => RunImageArchive rename
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Work-around JDK-8317609 (jdk.jcmd module doesn't verify)
 - Fix tests after merge
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Implementation for run-image link and single-hop
   
   This uses a stamp file in 'lib/modules' jimage in order to recognize
   multi-hop links. However, this has the caveat of no longer producing
   reproducible builds as compared to a packaged module-based link.
   
   Add an option to allow for multi-hop, which disables the stamp file
   addition and makes it reproducible again.
 - Exit the jlink on modified files by default
   
   This is configurable so add tests for both scenarios.
 - Use 'run-image' as the term shown with --verbose
 - ... and 1 more: https://git.openjdk.org/jdk/compare/5f69bb94...ef1bca8c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/2e73e300..ef1bca8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=03-04

  Stats: 26128 lines in 783 files changed: 14468 ins; 6080 del; 5580 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From sgehwolf at openjdk.org  Mon Oct 16 13:46:17 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 16 Oct 2023 13:46:17 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 29 Sep 2023 16:42:37 GMT, Severin Gehwolf  wrote:

> The command line options to override and change the error to a warning or silently ignore seems to be "-run-time-ignore-single-hop" and "--run-image-only-warnings". Maybe it should be reduced to just one option and maybe it should contain the word "clone" to something that makes it more obvious that it's just copying or cloning the contents of the modules in the run-time image

After some more thought I've changed my mind and I've come to the conclusion that it makes sense to combine them. The latest patch uses `--unlock-run-image` as the "force" option which demotes the error to a warning.

Perhaps it makes sense to get some consensus on the naming parts at this point. The CSR seems a good vehicle for that and I've fleshed it out a bit now.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1764514749

From jlaskey at openjdk.org  Mon Oct 16 13:50:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 13:50:58 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview)
Message-ID: 

Update String Templates for a second preview. With the addition of

- Expression type and throws are determined from the `process` method of the processor type and not the processor type.

- Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .

- Raw (generic) process types are no longer an error.

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

Commit messages:
 - Accept qualified STR and RAW
 - String Templates (second preview)

Changes: https://git.openjdk.org/jdk/pull/16202/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315457
  Stats: 91 lines in 29 files changed: 29 ins; 30 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

PR: https://git.openjdk.org/jdk/pull/16202

From mdoerr at openjdk.org  Mon Oct 16 14:06:09 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Oct 2023 14:06:09 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v3]
In-Reply-To: 
References: 
Message-ID: 

> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Support 4-byte aligned doubles in structures.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16179/files
  - new: https://git.openjdk.org/jdk/pull/16179/files/42d38e06..cba58ed0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16179&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16179&range=01-02

  Stats: 30 lines in 2 files changed: 20 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16179/head:pull/16179

PR: https://git.openjdk.org/jdk/pull/16179

From mdoerr at openjdk.org  Mon Oct 16 14:06:11 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Oct 2023 14:06:11 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v3]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
 
 <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>
 
 
 
 
 
Message-ID: 

On Sat, 14 Oct 2023 18:01:00 GMT, Jorn Vernee  wrote:

>> I was thinking something like this:
>> 
>> 
>> diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>> index dbd9a3f67a4..10b371457b3 100644
>> --- a/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>> +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>> @@ -180,6 +180,11 @@ private void checkLayout(MemoryLayout layout) {
>>          }
>>      }
>>  
>> +    // some ABIs have special handling for struct members
>> +    protected void checkStructMember(MemoryLayout member, long offset) {
>> +        checkLayoutRecursive(member);
>> +    }
>> +
>>      private void checkLayoutRecursive(MemoryLayout layout) {
>>          if (layout instanceof ValueLayout vl) {
>>              checkSupported(vl);
>> @@ -191,7 +196,7 @@ private void checkLayoutRecursive(MemoryLayout layout) {
>>                  // check element offset before recursing so that an error points at the
>>                  // outermost layout first
>>                  checkMemberOffset(sl, member, lastUnpaddedOffset, offset);
>> -                checkLayoutRecursive(member);
>> +                checkStructMember(member, offset);
>>  
>>                  offset += member.byteSize();
>>                  if (!(member instanceof PaddingLayout)) {
>> diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
>> index c24d2553ec0..f70af2bc025 100644
>> --- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
>> +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java
>> @@ -36,19 +36,14 @@
>>  import java.lang.invoke.MethodHandle;
>>  import java.lang.invoke.MethodType;
>>  import java.nio.ByteOrder;
>> -import java.util.HashMap;
>>  import java.util.Map;
>>  
>>  public final class AixPPC64Linker extends AbstractLinker {
>>  
>> -    static final Map CANONICAL_LAYOUTS;
>> +    static final Map CANONICAL_LAYOUTS
>> +            = SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT);
>>  
>> -    static {
>> -        HashMap layouts = new HashMap<>();
>> -        layouts.putAll(SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT));
>> -        layouts.put("do...
>
> Err, actually using `member.equals(C_DOUBLE)` in the above doesn't work since it still checks alignment. What you have with checking for `ValueLayout` and `carrier() == double.class` is better, but the byte order should also be checked at some point.

Please take a look at commit number 4. I think we need to support both, 4-byte and 8-byte aligned doubles in structures. IBM recommends to use "#pragma align (natural)": "The power suboption is the default to ensure compatibility with existing objects. If compatibility with earlier versions is not necessary, you should consider using natural alignment to improve potential application performance." https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.1?topic=pragmas-pragma-align
We could also recommend to use "#pragma align (natural)" for the FFI (and possibly for tests). That would reduce incompatibility with other platforms. I can file a subtask for test adaptation if needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1360709308

From alanb at openjdk.org  Mon Oct 16 14:30:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 14:30:15 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview)
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 13:41:55 GMT, Jim Laskey  wrote:

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

src/java.base/share/classes/java/lang/StringConcatHelper.java line 136:

> 134:      * @param value       value to mix in
> 135:      * @return            new length and coder
> 136:      * @since 22

The @since will be bumped when the feature becomes permanent, no need to bump it for the second preview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360750529

From jlaskey at openjdk.org  Mon Oct 16 14:35:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 14:35:37 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview)
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 14:27:05 GMT, Alan Bateman  wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 136:
> 
>> 134:      * @param value       value to mix in
>> 135:      * @return            new length and coder
>> 136:      * @since 22
> 
> The @since will be bumped when the feature becomes permanent, no need to bump it for the second preview.

Wasn't sure about that. Thx.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360757078

From mcimadamore at openjdk.org  Mon Oct 16 14:46:07 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Oct 2023 14:46:07 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v3]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
 
 <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>
 
 
 
 
 
 
Message-ID: 

On Mon, 16 Oct 2023 13:57:11 GMT, Martin Doerr  wrote:

>> Err, actually using `member.equals(C_DOUBLE)` in the above doesn't work since it still checks alignment. What you have with checking for `ValueLayout` and `carrier() == double.class` is better, but the byte order should also be checked at some point.
>
> Please take a look at commit number 4. I think we need to support both, 4-byte and 8-byte aligned doubles in structures. IBM recommends to use "#pragma align (natural)": "The power suboption is the default to ensure compatibility with existing objects. If compatibility with earlier versions is not necessary, you should consider using natural alignment to improve potential application performance." https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.1?topic=pragmas-pragma-align
> We could also recommend to use "#pragma align (natural)" for the FFI (and possibly for tests). That would reduce incompatibility with other platforms. I can file a subtask for test adaptation if needed.

Hi @TheRealMDoerr - yes, last weekend I read some bits from the AIX ABI, and it does seem that the more optimized variant is the "natural" variant, as that respects data alignment. As you write "power" seems to be the default, out of some compatibility constraints. But I think the main point that Jorn and I are trying to make is that the fact that "power" behaves in the way it does (e.g. it aligns all double fields after the first one at 4 bytes, rather than 8) has nothing to do with the intrinsic alignment of a double in AIX. E.g. the `double` type in AIX has alignment 8 (and you can check that using `alignof`). Then, it seems like all structs in AIX are compiled as if by using a pack pragma - and _that_ is what causes some double fields to feature a more packed alignment constraints.

Where does this leave us? There are few options:

* As you say, one option would be to just say that on AIX we only support the "natural" variant. This is similar to what we do on other platforms, where we do not support passing packed structs to functions (and what the javadoc of Linker says).
* Another option is to relax the Linker javadoc so that struct layouts are completely Linker specific. This would allow the AIX linker to support whatever alignment is requested.

I have very little experience with AIX, so I'm not in a position to say how much the first option would be perceived as a restriction or not. The nice thing about the first option is that clients of FFM do not have to worry about structs in AIX having special rules. But, perhaps that's an unrealistic goal anyway, and I can imagine other ABIs also going down the path of specifying various packed representations which are not supported by the current javadoc text.

Perhaps, from a logistical point of view, starting off with "natural" for now, and then relaxing the documentation later, and add support for packed structs, would be better, as the changes would be more localized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1360770647

From duke at openjdk.org  Mon Oct 16 15:00:42 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 15:00:42 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: 

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Use StringConcatFactory.makeConcatWithConstants

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/88b1b13c..013ceffb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=05-06

  Stats: 47 lines in 1 file changed: 42 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From duke at openjdk.org  Mon Oct 16 15:23:47 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 15:23:47 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v6]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 17:01:11 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use % calculate lowInt

I have found the reason. Using the following recipe is faster every time:

MethodType.methodType(String.class, long.class, char.class, char.class, char.class),
                            "\1\1\1\1"


* Using the following recipe is sometimes faster and sometimes slower, because there is a prepare(long indexCoder, byte[] buf, String value) operation here

MethodType.methodType(String.class, long.class, char.class, char.class),
                            "\1.\1\1"

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1764634547

From mbaesken at openjdk.org  Mon Oct 16 15:52:47 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Oct 2023 15:52:47 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken  wrote:

>> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
>> Some examples :
>> Events::log_dll_message for hs-err files reporting
>> JFR event NativeLibraryLoad
>> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
>> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
>> 
>> Offer an interface (e.g. jvm.cpp) to support this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows aarch64 build issues

Hello, any comments about the idea of calling into 'os::dll_load' instead ? That would indeed make the coding smaller and less 'messy' .

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

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1764687056

From redestad at openjdk.org  Mon Oct 16 16:09:11 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Oct 2023 16:09:11 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

Good, narrows it down to what's going on in `prepend(long, byte[], String)`. Might boil down to `System.arraycopy`. This method might not be optimized for tiny arrays on all platforms. Specializing for single-char case:


diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
index 9b19d7e2ac1..6eb70925dab 100644
--- a/src/java.base/share/classes/java/lang/String.java
+++ b/src/java.base/share/classes/java/lang/String.java
@@ -4723,7 +4723,11 @@ static void repeatCopyRest(byte[] buffer, int offset, int limit, int copied) {
      */
     void getBytes(byte[] dst, int dstBegin, byte coder) {
         if (coder() == coder) {
-            System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
+            if (value.length == 1) {
+                dst[(dstBegin << coder)] = value[0];
+            } else {
+                System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
+            }
         } else {    // this.coder == LATIN && coder == UTF16
             StringLatin1.inflate(value, 0, dst, dstBegin, value.length);
         }

.. seem to help the JIT do the right thing consistently, too:

Benchmark                                 Mode  Cnt   Score   Error  Units
BigDecimals.testSmallToEngineeringString  avgt   50  11,757 ? 0,480  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1764787645

From darcy at openjdk.org  Mon Oct 16 16:17:40 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 16 Oct 2023 16:17:40 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases
Message-ID: 

A new paper

 "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
https://members.loria.fr/PZimmermann/papers/accuracy.pdf

details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

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

Commit messages:
 - Fix typo found in code review.
 - Add stated error bounds.
 - JDK-8316708: Augment WorstCaseTests with more cases

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

PR: https://git.openjdk.org/jdk/pull/15879

From darcy at openjdk.org  Mon Oct 16 16:17:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 16 Oct 2023 16:17:42 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases
In-Reply-To: 
References: 
Message-ID: 

On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy  wrote:

> A new paper
> 
>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

Since the error bars for sinh and cosh are larger, I didn't include those cases. FDLIBM pow has a bug where the actual error is outside of the spec'ed error bounds so that case is that included in this update.

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

PR Comment: https://git.openjdk.org/jdk/pull/15879#issuecomment-1730828467

From rgiulietti at openjdk.org  Mon Oct 16 16:17:59 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 16 Oct 2023 16:17:59 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases
In-Reply-To: 
References: 
Message-ID: 

On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy  wrote:

> A new paper
> 
>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

test/jdk/java/lang/Math/WorstCaseTests.java line 56:

> 54:  * sinh and cosh.
> 55:  *
> 56:  * Additional worst-case observed error inputs for the FDLIBM-dervied

Suggestion:

 * Additional worst-case observed error inputs for the FDLIBM-derived

test/jdk/java/lang/Math/WorstCaseTests.java line 230:

> 228: 
> 229:             // Worst-case observed error
> 230:             {-0x1.004d1c5a9400bp-1,    -0x1.0c6e322e8a28cp-1},

It seems that the exact value y meets `-0x1.0c6e322e8a28cp-1` < y < `-0x1.0c6e322e8a28bp-1`, and is closer to `-0x1.0c6e322e8a28bp-1`.
Thus, the correctly rounded result is `-0x1.0c6e322e8a28bp-1`.
The truncated (expected) value should be `-0x1.0c6e322e8a28bp-1` as well.

test/jdk/java/lang/Math/WorstCaseTests.java line 266:

> 264: 
> 265:             // Worst-case observed error
> 266:             {-0x1.34e729fd08086p+21,    +0x1.6a6a0d6a17f0fp-1},

Both `Math.cos` and `StrictMath.cos` produce the correctly rounded result here.
I don't know why the paper says otherwise. Perhaps OpenLibm is not exactly fdlibm.

test/jdk/java/lang/Math/WorstCaseTests.java line 293:

> 291: 
> 292:             // Worst-case observed error
> 293:             {-0x1.0068b067c6feep-1,     +0x1.0c335e2f0727p1},

Similar considerations as for asin above.
The "expected" value should be `0x1.0c335e2f0726fp1`.

test/jdk/java/lang/Math/WorstCaseTests.java line 325:

> 323: 
> 324:             // Worst-case observed error
> 325:             {0x1.3f9605aaeb51bp+21,     -0x1.9678ee5d64935p-1},

The given expected value seems to contradict the introductory comment.
The exact value y meets `-0x1.9678ee5d64935p-1` < y < `-0x1.9678ee5d64934p-1`, and is closer to `-0x1.9678ee5d64935p-1`.
Thus, the rounded value of y is `-0x1.9678ee5d64935p-1`, but its truncated value is `-0x1.9678ee5d64934p-1`.
This should be the expected value, but then the test fails.

I don't think that the test logic can support errors > 1 ulp, as is the case here.
Perhaps, rather than a single expected value, there should be explicit lower and upper bounds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334533881
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334537273
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334556250
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334539144
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334533360

From duke at openjdk.org  Mon Oct 16 16:17:47 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:17:47 GMT
Subject: RFR: 8316150: Refactor get chars and string size
Message-ID: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>

1. Reduce duplicate stringSize code
2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method

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

Commit messages:
 - Revert FormatItem related changes
 - restore StringUTF16.getChars(int,int,int,byte[]) and StringUTF16.getChars(long,int,int,byte[])
 - bug fix FormatItemDecimal::prepend
 - fix build error
 - refactor & bug fix
 - remove unused throws
 - remove unused throws
 - refactor from #15836
 - bug fix for DecimalDigits#getCharsUTF16(int, int, byte[])
 - remove unused code
 - ... and 17 more: https://git.openjdk.org/jdk/compare/d3e82183...d4f55ddc

Changes: https://git.openjdk.org/jdk/pull/15699/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316150
  Stats: 620 lines in 11 files changed: 279 ins; 303 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/15699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15699/head:pull/15699

PR: https://git.openjdk.org/jdk/pull/15699

From darcy at openjdk.org  Mon Oct 16 16:18:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 16 Oct 2023 16:18:06 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 15:27:51 GMT, Raffaello Giulietti  wrote:

>> A new paper
>> 
>>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>> 
>> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.
>
> test/jdk/java/lang/Math/WorstCaseTests.java line 325:
> 
>> 323: 
>> 324:             // Worst-case observed error
>> 325:             {0x1.3f9605aaeb51bp+21,     -0x1.9678ee5d64935p-1},
> 
> The given expected value seems to contradict the introductory comment.
> The exact value y meets `-0x1.9678ee5d64935p-1` < y < `-0x1.9678ee5d64934p-1`, and is closer to `-0x1.9678ee5d64935p-1`.
> Thus, the rounded value of y is `-0x1.9678ee5d64935p-1`, but its truncated value is `-0x1.9678ee5d64934p-1`.
> This should be the expected value, but then the test fails.
> 
> I don't think that the test logic can support errors > 1 ulp, as is the case here.
> Perhaps, rather than a single expected value, there should be explicit lower and upper bounds.

For FDLIBM tan, the stated error in the Math.tan spec is 1 ulp and the FDLIBM sources say tan is "nearly rounded," which could reasonably be interpreted as meaning within 1 ulp. However, the reported error by the paper is 1.02 ulps.

As you note here, the current testing methodology can only really deal with at most a 1 ulp error, assuming the expected value is at the lower endpoint of the range.

To avoid any lurking errors in the FDLIBM port to Java, I generated the expected numbers running jshell on JDK 20, which uses the mostly C-based FDLIBM. For a number of cases I had to decrement the expected value for the test to pass against Math and StrictMath. The decremented value and its successor may or may not bracket the exact value; I didn't verify that.

In other words, there may be other bugs in one or both math libraries the test is detecting.

So far, I've only tried running the test locally, but this would need a cross-platform run being before pushed to cover all the intrinsics that may be in use on the full set of supported platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334831427

From duke at openjdk.org  Mon Oct 16 16:17:56 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:17:56 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
Message-ID: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>

@cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.

The following are the test results based on MacBookPro M1 Pro: 


-Benchmark                          Mode  Cnt     Score     Error  Units
-StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
-StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
-StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
-StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
-StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
-StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
-StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
-StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op

+Benchmark                          Mode  Cnt    Score    Error  Units
+StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
+StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
+StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
+StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
+StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
+StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
+StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
+StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

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

Commit messages:
 - move testcases to Basic.java
 - move testcase from BasicInt to Basic-X
 - add copyright info
 - Improve the readability, suggestion from @rgiulietti
 - Improve the readability of parseArgument, suggestion from @rgiulietti
 - Fix from @rgiulietti review
 - Refactor according to rgiulietti's suggestion and add testcases
 - fix : the exception thrown when the input does not include conversion is different from baselne.
 - code format
 - refactor for review & remove comment
 - ... and 25 more: https://git.openjdk.org/jdk/compare/a2391a92...bce554a8

Changes: https://git.openjdk.org/jdk/pull/15776/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316704
  Stats: 248 lines in 4 files changed: 212 ins; 14 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/15776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15776/head:pull/15776

PR: https://git.openjdk.org/jdk/pull/15776

From liach at openjdk.org  Mon Oct 16 16:18:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 16 Oct 2023 16:18:01 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
Message-ID: 

On Wed, 13 Sep 2023 01:24:05 GMT, Shaojin Wen  wrote:

> 1. Reduce duplicate stringSize code
> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method

Changes requested by liach (Author).

Changes requested by liach (Author).

Do Octal and Hex digits need int versions of getChars and stringSize?

Since the current `MethodHandle`-based char putter can only put 1-byte at once, have you considered something like this:

// A replacement for setter MethodHandle, or VarHandle, to accept multiple value types
public interface DigitConsumer {
    void putChar(byte[] array, int index, byte value);
    // put 2 byte-sized chars at once, encoded little endian
    void putChar2(byte[] array, int index, short value);
    // you can add putChar4, putChar8, etc. if you need
}

and `StringConcatHelper.selectPutChar` will return a `DigitConsumer` instead of a `MethodHandle`.

Currently, you are allocating a new byte array for every number in the format, which I deem very inefficient.

src/java.base/share/classes/java/util/FormatItem.java line 148:

> 146:             int length = DecimalDigits.stringSize(value);
> 147:             this.digits = new byte[length];
> 148:             DecimalDigits.getCharsLatin1(value, length, this.digits);

Sorry missed this one in last round of review. This is wrong if you mix number fornat items and chinese segments in a String Template.

src/java.base/share/classes/java/util/FormatItem.java line 248:

> 246:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {
> 247:             MethodHandle putCharMH = selectPutChar(lengthCoder);
> 248:             HexDigits.getCharsLatin1(value, (int)lengthCoder, buffer);

This is wrong if the coder is UTF16

src/java.base/share/classes/java/util/FormatItem.java line 296:

> 294:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {
> 295:             MethodHandle putCharMH = selectPutChar(lengthCoder);
> 296:             OctalDigits.getCharsLatin1(value, (int)lengthCoder, buffer);

Same, wrong for UTF16

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 216:

> 214:      */
> 215:     public static int getCharsLatin1(int i, int index, byte[] buf) {
> 216:         // Used by trusted callers.  Assumes all necessary bounds checks have been done by the caller.

Can you move this into the javadoc, like

Caller must ensure buf has enough capacity for the value to be written!

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

PR Review: https://git.openjdk.org/jdk/pull/15699#pullrequestreview-1623691652
PR Review: https://git.openjdk.org/jdk/pull/15699#pullrequestreview-1639167213
PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1730795452
PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1732267099
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1334265520
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1333894410
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1333894660
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1323970440

From redestad at openjdk.org  Mon Oct 16 16:18:10 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Oct 2023 16:18:10 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: 

On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen  wrote:

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

It might be reasonable to add a few more common patterns to the `FormatSpecifier` fast-path, but where to draw the line?

FWIW the intent of micros like `complex` and `widthString` wasn't necessarily to invite further optimizations, but to explore the cost of failure, i.e., make sure that the fast-path doesn't add a substantial cost when it doesn't help or only helps somewhat. Since you now specialize for most of the patterns in the micros I think you need to explore some variants that you _don't_ optimize for, such as `"%10.3f"`. 

Orthogonal optimizations like the `FormatSpecifier` fast-path extension and the `print` fast-path should generally be separate PRs.

I think it would make sense to make the testing a bit more exhaustive, especially w.r.t argument indexes and specifiers taking multiple flags. Looking at test/jdk/java/util/Formatter/Basic-X.java.template we seem to test each flag, but lack tests combining many flags and permutations thereof. Could you take a stab at increasing coverage a bit here?

I'm also curious what performance numbers you get with the latest patch. If we go all the way like this some of the added microbenchmarks is a bit pointless so after checking you might want to cut back on some of those (just keep one of the floating point tests maybe)

I think this is shaping up nicely. Some unused code, then I think we can move ahead.

The new `FormatSpecifierParser` utility class adds a bit of boilerplate for something that could be a static utility: https://github.com/wenshao/jdk/pull/6 - but perhaps splitting it up a bit more helps JIT inlining further. I can take this on as a follow-up RFE if you prefer.

A few nits, otherwise I think this looks OK

I was worried this would sprawl out more, but perhaps ~230 lines of code is a reasonable extra weight to make the long tail of `String.format`'s  regex-free.

I was going to comment that the flag parsing was broken in f303f29 but it seems that it was fixed in the latest. I think we need to make a review pass over all existing tests to make sure all imaginable variants are covered.

The parser code also ought to be shared between `Formatter` and `FormatProcessor` so that there's a single source of truth going forward.

I think it makes sense to file an RFE and do a full review of this. "Regex-free parsing of Formatter and FormatProcessor specifiers"?

Please don't pile on new refactorings and improvements on a PR that has been opened for review. Better to let things brew as a draft for a bit if you're not sure you're done before opening the PR for review, then once it's been opened (like this one) consider preparing follow-up PR instead of refactoring as you go.

Specifically I'm not sure 0d977b2 is a good idea and would like you to roll those changes back. Object pooling for trivial, short-lived objects are considered an anti-pattern, as they add references to old GC generations and share many of the same drawbacks as lookup tables, such as increased cache traffic. Showing great wins on microbenchmarks while being a wash or even regressing real applications.

src/java.base/share/classes/java/util/Formatter.java line 2944:

> 2942:                             ++off;
> 2943:                             argSize = size + 1;
> 2944:                             size = 0;

pointless `size = 0`

src/java.base/share/classes/java/util/Formatter.java line 2949:

> 2947:                             }
> 2948:                         } else {
> 2949:                             if (first == '0') {

While it's clever to avoid re-parsing I think it muddies the control flow. It would be simpler if we always reset to `off = start; c = first` in this `else` block then unconditionally call `parseFlags(); parseWidth();` outside in `parse`. The few extra calls to `s.charAt(..)` this might add a little overhead on some tests, but the JIT might like the brevity and less branchy structure overall and on larger benchmarks.. Maybe worth experimenting with.

src/java.base/share/classes/java/util/Formatter.java line 2964:

> 2962:                                 widthSize = size;
> 2963:                             }
> 2964:                             size = 0;

Pointless `size = 0`

src/java.base/share/classes/java/util/Formatter.java line 2977:

> 2975:                 if (!Flags.isFlag(c)) {
> 2976:                     flagSize = size;
> 2977:                     size = 0;

pointless `size = 0`

src/java.base/share/classes/java/util/Formatter.java line 3011:

> 3009: 
> 3010:     static boolean isConversion(char c) {
> 3011:         return (c >= 'a' && c <= 'z') || (c >= 'A' || c <= 'Z') || c == '%';

Logical error:
Suggestion:

        return (c >= 'a' && c <= 'z') || (c >= 'A' && c <= 'Z') || c == '%';

src/java.base/share/classes/java/util/Formatter.java line 3140:

> 3138:         }
> 3139: 
> 3140:         FormatSpecifier(char conv, int flag, int width, int precision) {

This appears to be unused.

src/java.base/share/classes/java/util/Formatter.java line 3420:

> 3418:                     && fmt.a instanceof StringBuilder sb
> 3419:             ) {
> 3420:                 sb.append(value);

There's a lot of `if`s here, and this doesn't take into account locales with non-ASCII digits:

Locale ar = new Locale.Builder().setLanguageTag("ar-SA-u-nu-arab").build();
Locale.setDefault(ar);
System.out.println("%d".formatted(10000)); // should print "?????" but prints "10000"

test/jdk/java/util/Formatter/Basic-X.java.template line 1748:

> 1746:         // perhaps an IllegalFormatArgumentIndexException should be defined?
> 1747:         tryCatch("%<%", IllegalFormatFlagsException.class);
> 1748: 

After adding test-cases to this template you need to run `genBasic.sh` (in the same folder) to regenerate all the `Basic*` tests. These changes then need to be added to the PR.

FWIW these new and existing tests that provoke `IllegalFormatPrecisionException` and `UnknownFormatConversionException` are common to all types, meaning there seems to be little point in generating them out into each and every `BasicByte`, `BasicInt` et.c.. Perhaps it would make more sense to add such tests directly to Basic.java to avoid some redundancy here - or a new `BasicCommon` test to put common tests into?

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

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1630133740
PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1639452604
Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1641781843
Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1641961236
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1728424181
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1730173405
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1732562759
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335806486
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335817101
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335817800
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335779111
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335234147
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335667901
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1328152682
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1350933399

From duke at openjdk.org  Mon Oct 16 16:18:05 2023
From: duke at openjdk.org (wickund)
Date: Mon, 16 Oct 2023 16:18:05 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
Message-ID: <9bxc1uJ5BM5Njd3wJyOwQn_jvMtVdTlVF3XEFvQiEZI=.93df496a-b9ed-4bd5-832b-90e1b2a80b9c@github.com>

On Wed, 13 Sep 2023 01:24:05 GMT, Shaojin Wen  wrote:

> 1. Reduce duplicate stringSize code
> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method

Changes requested by wickund at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/15699#pullrequestreview-1639806273

From rgiulietti at openjdk.org  Mon Oct 16 16:18:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 16 Oct 2023 16:18:17 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: 

On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen  wrote:

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

For maintainability purposes, we should strive for simplicity and readability.

The parser looks good (but see the small proposed enhancements).

I'll continue with the rest tomorrow.

You might consider this alternative, which IMO is simpler and more readable.


        int parse() {
            // %[argument_index$][flags][width][.precision][t]conversion
            // %(\d+$)?([-#+ 0,(<]*)?(\d+)?(.\d+)?([tT])?([a-zA-Z%])
            parseArgument();
            parseFlag();
            parseWidth();
            int precisionSize = parsePrecision();
            if (precisionSize < 0) {
                return 0;
            }

            // ([tT])?([a-zA-Z%])
            char t = '\0', conversion = '\0';
            if ((c == 't' || c == 'T') && off + 1 < max) {
                char c1 = s.charAt(off + 1);
                if (isConversion(c1)) {
                    t = c;
                    conversion = c1;
                    off += 2;
                }
            }
            if (conversion == '\0' && isConversion(c)) {
                conversion = c;
                ++off;
            }

            if (argSize + flagSize + widthSize + precisionSize + t + conversion != 0) {
                if (al != null) {
                    FormatSpecifier formatSpecifier
                            = new FormatSpecifier(s, start, argSize, flagSize, widthSize, precisionSize, t, conversion);
                    al.add(formatSpecifier);
                }
                return off - start;
            }
            return 0;
        }

        private void parseArgument() {
            // (\d+$)?
            int i = off;
            for (; i < max && isDigit(c = s.charAt(i)); ++i);  // empty body
            if (i == max || c != '$') {
                c = first;
                return;
            }
            ++i;  // skip '$'
            if (i < max) {
                c = s.charAt(i);
            }
            argSize = i - off;
            off = i;
        }

        private void parseFlag() {
            // ([-#+ 0,(<]*)?
            int i = off;
            for (; i < max && Flags.isFlag(c = s.charAt(i)); ++i);  // empty body
            flagSize = i - off;
            off = i;
        }

        private void parseWidth() {
            // (\d+)?
            int i = off;
            for (; i < max && isDigit(c = s.charAt(i)); ++i);  // empty body
            widthSize = i - off;
            off = i;
        }

        private int parsePrecision() {
            // (.\d+)?
            if (c != '.') {
                return 0;
            }
            int i = off + 1;
            for (; i < max && isDigit(c = s.charAt(i)); ++i);  // empty body
            if (i == off + 1) {  // a '.' but no digits
                return -1;
            }
            int size = i - off;
            off = i;
            return size;
        }

Meaningful external reviews take a _lot_ of engineering time on such a popular platform as the JDK.
They make sense only on somehow stable code, otherwise they are a waste of human resources.

So sure, take your time to stabilize your code, make your tests, but please refrain from keep on changing too much once you publish a PR. If reviewers have to face continuous changes, they might become uninterested in reviewing.

src/java.base/share/classes/java/util/Formatter.java line 2899:

> 2897:             if (c == '.') {
> 2898:                 // (\.\d+)?
> 2899:                 precisionSize = parsePrecision();

`precisionSize == 0` has two different meanings: (1) there's a '.' not followed by digits and (2) there's no precision field at all.

In the proposed [alternative](https://github.com/openjdk/jdk/pull/15776#issuecomment-1737986458), case (1) is indicated by `-1`, while case (2) is indicated by `0`. Besides, the decision is taken in the `parsePrecision()` method, not partly here and partly in the method.

src/java.base/share/classes/java/util/Formatter.java line 2918:

> 2916:                 conversion = c;
> 2917:                 ++off;
> 2918:             }

Suggestion:

            } else if (isConversion(c)) {
                conversion = c;
                ++off;
            }

src/java.base/share/classes/java/util/Formatter.java line 2933:

> 2931:         private void parseArgument() {
> 2932:             // (\d+\$)?
> 2933:             for (int size = 0; off < max; c = s.charAt(++off), size++) {

This argument_index parser is incorrect.

Say the invalid "specifier" is `"%12"`.
The parser would throw a `StringIndexOutOfBoundsException` on `s.charAt(++off)`.

src/java.base/share/classes/java/util/Formatter.java line 2934:

> 2932:             // (\d+\$)?
> 2933:             int i = off;
> 2934:             for (; i < max && isDigit(c); c = next(++i));  // empty body

No need for `next()` if done as in the proposed alternative.

src/java.base/share/classes/java/util/Formatter.java line 2947:

> 2945:                     c = first;
> 2946:                 }
> 2947:             }

I think the logic in the proposed alternative is more readable.

src/java.base/share/classes/java/util/Formatter.java line 2953:

> 2951:             // ([-#+ 0,(\<]*)?
> 2952:             int i = off;
> 2953:             for (; i < max && Flags.isFlag(c); c = next(++i));  // empty body

No need for `next()` if done as in the proposed alternative.

src/java.base/share/classes/java/util/Formatter.java line 2961:

> 2959:             // (\d+)?
> 2960:             int i = off;
> 2961:             for (; i < max && isDigit(c); c = next(++i));  // empty body

You are using `next()` here, but the simpler solution in `parsePrecision()`.
I think consistency simplifies understanding.

src/java.base/share/classes/java/util/Formatter.java line 2966:

> 2964: 
> 2965:         private int parsePrecision() {
> 2966:             // (\.\d+)?

Since processing of `'.'` is done by the caller, the regex pattern in this comment is confusing.
Either prefer handling `'.'` here (see [this](https://github.com/openjdk/jdk/pull/15776#issuecomment-1737986458)), or adjust the regex in the comment.

src/java.base/share/classes/java/util/Formatter.java line 2978:

> 2976:         }
> 2977: 
> 2978:         private char next(int off) {

There's no real need for this more expensive method, compared with a simple `s.charAt(i)`, in the alternative proposed [before](https://github.com/openjdk/jdk/pull/15776#issuecomment-1737986458).

src/java.base/share/classes/java/util/Formatter.java line 3136:

> 3134:             int flagEnd = argEnd + flagSize;
> 3135:             int widthEnd = flagEnd + widthSize;
> 3136:             int precesionEnd = widthEnd + precisionSize;

Suggestion:

            int precisionEnd = widthEnd + precisionSize;

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

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1647449239
PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1660250320
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1737986458
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1739462969
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1339852931
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1347671680
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1338962488
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1339856693
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1339856725
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1339857403
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1339844252
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1347679848
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1339842414
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1339135086

From jlaskey at openjdk.org  Mon Oct 16 16:18:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 16:18:06 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
Message-ID: 

On Wed, 13 Sep 2023 01:24:05 GMT, Shaojin Wen  wrote:

> 1. Reduce duplicate stringSize code
> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method

Changes requested by jlaskey (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15699#pullrequestreview-1639826354

From duke at openjdk.org  Mon Oct 16 16:18:17 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:17 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: 

On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen  wrote:

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

I enhanced parse fast-path to support more specifiers, including:

% flag_1 width_1
% flag_2
% width_2
% width_1 . precesion_1


now benchmark on macbook m1 pro result is:

-Benchmark                           Mode  Cnt     Score     Error  Units (optimized)
-StringFormat.complexFormat          avgt   15  2049.387 ? 121.539  ns/op
-StringFormat.flags2Format           avgt   15   430.964 ?   2.414  ns/op
-StringFormat.flagsFormat            avgt   15   257.851 ?  23.833  ns/op
-StringFormat.stringFormat           avgt   15    63.564 ?  10.490  ns/op
-StringFormat.stringIntFormat        avgt   15    88.111 ?   0.678  ns/op
-StringFormat.width2Format           avgt   15   349.304 ?  31.349  ns/op
-StringFormat.width2PrecisionFormat  avgt   15   464.621 ?  53.918  ns/op
-StringFormat.widthFormat            avgt   15   301.997 ?  34.974  ns/op
-StringFormat.widthPrecisionFormat   avgt   15   484.526 ?  38.098  ns/op
-StringFormat.widthStringFormat      avgt   15   235.421 ?  32.955  ns/op
-StringFormat.widthStringIntFormat   avgt   15   315.178 ?  15.154  ns/op

+Benchmark                           Mode  Cnt    Score    Error  Units
+StringFormat.complexFormat          avgt   15  702.407 ? 85.481  ns/op (+191.77)
+StringFormat.flags2Format           avgt   15  329.551 ?  1.610  ns/op (+30.78)
+StringFormat.flagsFormat            avgt   15  125.798 ?  1.109  ns/op (+104.98)
+StringFormat.stringFormat           avgt   15   60.029 ?  6.275  ns/op (+5.89)
+StringFormat.stringIntFormat        avgt   15   89.020 ?  0.575  ns/op (-1.03)
+StringFormat.width2Format           avgt   15  135.743 ?  0.643  ns/op (+157.33)
+StringFormat.width2PrecisionFormat  avgt   15  351.408 ? 21.031  ns/op (+32.22)
+StringFormat.widthFormat            avgt   15  208.843 ? 47.504  ns/op (+44.61)
+StringFormat.widthPrecisionFormat   avgt   15  354.375 ? 67.314  ns/op (+36.73)
+StringFormat.widthStringFormat      avgt   15   74.846 ? 19.604  ns/op (+214.55)
+StringFormat.widthStringIntFormat   avgt   15  101.638 ?  0.961  ns/op (+210.10)

> I was worried this would sprawl out more, but perhaps ~230 lines of code is a reasonable extra weight to make the long tail of `String.format`'s regex-free.
> 
> I was going to comment that the flag parsing was broken in [f303f29](https://github.com/openjdk/jdk/commit/f303f2959d108d993dc03e86a27ef42bb892647f) but it seems that it was fixed in the latest. I think we need to make a review pass over all existing tests to make sure all imaginable variants are covered.
> 
> The parser code also ought to be shared between `Formatter` and `FormatProcessor` so that there's a single source of truth going forward.

The codes of Formatter and FormatProcessor have been regex-free. There are many changes and require more detailed review.

I will delete redundant performance tests later. and I will delete redundant performance tests ,The current results are as follows :

# Performance Numbers

## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
* cpu : intel xeon sapphire rapids (x64)
* os debian linux


-Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
-StringFormat.complexFormat          avgt   15  1426.696 ? 18.469  ns/op
-StringFormat.flags2Format           avgt   15   164.141 ?  2.264  ns/op
-StringFormat.flagsFormat            avgt   15   169.313 ?  6.616  ns/op
-StringFormat.stringFormat           avgt   15    34.710 ?  0.075  ns/op
-StringFormat.stringIntFormat        avgt   15    85.152 ?  0.337  ns/op
-StringFormat.width2Format           avgt   15   242.483 ?  5.586  ns/op
-StringFormat.width2PrecisionFormat  avgt   15   282.838 ?  2.564  ns/op
-StringFormat.widthFormat            avgt   15   175.460 ?  4.458  ns/op
-StringFormat.widthPrecisionFormat   avgt   15   244.593 ?  3.605  ns/op
-StringFormat.widthStringFormat      avgt   15   144.487 ?  5.271  ns/op
-StringFormat.widthStringIntFormat   avgt   15   223.913 ?  6.387  ns/op

+Benchmark                           Mode  Cnt    Score    Error  Units  (59c2983b)
+StringFormat.complexFormat          avgt   15  582.650 ? 17.399  ns/op (+144.87)
+StringFormat.flags2Format           avgt   15   74.214 ?  0.703  ns/op (+121.18)
+StringFormat.flagsFormat            avgt   15   67.764 ?  0.572  ns/op (+149.86)
+StringFormat.stringFormat           avgt   15   34.659 ?  0.201  ns/op (+0.15)
+StringFormat.stringIntFormat        avgt   15   84.448 ?  0.532  ns/op (+0.84)
+StringFormat.width2Format           avgt   15  123.012 ?  0.513  ns/op (+97.13)
+StringFormat.width2PrecisionFormat  avgt   15  148.092 ?  1.273  ns/op (+90.99)
+StringFormat.widthFormat            avgt   15   69.575 ?  1.023  ns/op (+152.19)
+StringFormat.widthPrecisionFormat   avgt   15  116.187 ?  0.938  ns/op (+110.52)
+StringFormat.widthStringFormat      avgt   15   48.389 ?  0.298  ns/op (+198.60)
+StringFormat.widthStringIntFormat   avgt   15  103.617 ?  2.204  ns/op (+116.10)



## 2. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
* cpu : aliyun yitian 710 (aarch64)
* os debian linux


-Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
-StringFormat.complexFormat          avgt   15  2321.319 ?  9.624  ns/op
-StringFormat.flags2Format           avgt   15   310.377 ? 10.367  ns/op
-StringFormat.flagsFormat            avgt   15   295.118 ?  8.645  ns/op
-StringFormat.stringFormat           avgt   15    55.966 ?  0.949  ns/op
-StringFormat.stringIntFormat        avgt   15   157.949 ?  2.972  ns/op
-StringFormat.width2Format           avgt   15   380.621 ? 11.301  ns/op
-StringFormat.width2PrecisionFormat  avgt   15   447.285 ?  7.323  ns/op
-StringFormat.widthFormat            avgt   15   312.622 ?  5.104  ns/op
-StringFormat.widthPrecisionFormat   avgt   15   407.196 ?  6.466  ns/op
-StringFormat.widthStringFormat      avgt   15   248.538 ?  2.356  ns/op
-StringFormat.widthStringIntFormat   avgt   15   416.661 ?  6.685  ns/op

+Benchmark                           Mode  Cnt    Score    Error  Units (59c2983b)
+StringFormat.complexFormat          avgt   15  930.922 ? 91.995  ns/op (+149.36)
+StringFormat.flags2Format           avgt   15  132.746 ? 10.809  ns/op (+133.82)
+StringFormat.flagsFormat            avgt   15  119.267 ? 11.709  ns/op (+147.45)
+StringFormat.stringFormat           avgt   15   55.820 ?  0.324  ns/op (+0.27)
+StringFormat.stringIntFormat        avgt   15  154.045 ?  7.327  ns/op (+2.54)
+StringFormat.width2Format           avgt   15  177.655 ?  4.797  ns/op (+114.25)
+StringFormat.width2PrecisionFormat  avgt   15  236.680 ?  4.266  ns/op (+88.99)
+StringFormat.widthFormat            avgt   15  132.043 ? 15.730  ns/op (+136.76)
+StringFormat.widthPrecisionFormat   avgt   15  204.085 ? 10.300  ns/op (+99.53)
+StringFormat.widthStringFormat      avgt   15  106.971 ?  5.527  ns/op (+132.35)
+StringFormat.widthStringIntFormat   avgt   15  215.329 ?  3.786  ns/op (+93.50)

> Please don't pile on new refactorings and improvements on a PR that has been opened for review. Better to let things brew as a draft for a bit if you're not sure you're done before opening the PR for review, then once it's been opened (like this one) consider preparing follow-up PR instead of refactoring as you go.
> 
> Specifically I'm not sure [0d977b2](https://github.com/openjdk/jdk/commit/0d977b2febe455f4535e6ee2cb19d3b168d764e3) is a good idea and would like you to roll those changes back. Object pooling for trivial, short-lived objects are considered an anti-pattern, as they add references to old GC generations and share many of the same drawbacks as lookup tables, such as increased cache traffic. Showing great wins on microbenchmarks while being a wash or even regressing real applications.

Sorry, I will pay attention to it in the future and modify it in the open review code. I have revert commit to #0d977b2. I agree with your view on the performance issues of old reference.

int parse(List al, char first, int start, String s, int max)

java.util.Formatter::parse (469 bytes)   failed to inline: callee is too large

The reason why I split it into multiple small methods is to avoid a single method codeSize > 325. After merging small methods, the performance will decrease.

I know, so I'm asking for your opinion, and if you don't agree, I won't submit big changes. There have been a lot of changes now, and I will continue to complete this PR based on the current version.

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

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1723733247
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1730164585
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1731163579
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1732567054
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1733490226
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1740015776

From duke at openjdk.org  Mon Oct 16 16:18:15 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 16 Oct 2023 16:18:15 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
Message-ID: 

On Wed, 13 Sep 2023 01:24:05 GMT, Shaojin Wen  wrote:

> 1. Reduce duplicate stringSize code
> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method

The?`throws?Throwable` declarations are?no?longer?needed, as?the?prependers no?longer?depend on?`MethodHandle`s.

src/java.base/share/classes/java/util/FormatItem.java line 66:

> 64: 
> 65:     private static long stringPrepend(long lengthCoder, byte[] buffer,
> 66:                                             String value) throws Throwable {

Suggestion:

    private static long stringPrepend(long lengthCoder, byte[] buffer, String value) {

src/java.base/share/classes/java/util/FormatItem.java line 131:

> 129: 
> 130:         @Override
> 131:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        public long prepend(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 139:

> 137:         }
> 138: 
> 139:         private long prependLatin1(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        private long prependLatin1(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 180:

> 178:         }
> 179: 
> 180:         private long prependUTF16(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        private long prependUTF16(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 250:

> 248: 
> 249:         @Override
> 250:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        public long prepend(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 258:

> 256:         }
> 257: 
> 258:         protected long prependLatin1(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        protected long prependLatin1(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 271:

> 269:         }
> 270: 
> 271:         protected long prependUTF16(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        protected long prependUTF16(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 277:

> 275:             this.hasPrefix = hasPrefix;
> 276:             this.value = value;
> 277:             this.length = HexDigits.INSTANCE.size(value);

Suggestion:

            this.length = OctalDigits.INSTANCE.size(value);

src/java.base/share/classes/java/util/FormatItem.java line 318:

> 316: 
> 317:         @Override
> 318:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        public long prepend(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 326:

> 324:         }
> 325: 
> 326:         protected long prependLatin1(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        protected long prependLatin1(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 343:

> 341:         }
> 342: 
> 343:         protected long prependUTF16(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        protected long prependUTF16(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 383:

> 381: 
> 382:         @Override
> 383:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        public long prepend(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 412:

> 410: 
> 411:         @Override
> 412:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        public long prepend(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 524:

> 522: 
> 523:         @Override
> 524:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        public long prepend(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 559:

> 557: 
> 558:         @Override
> 559:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        public long prepend(long lengthCoder, byte[] buffer) {

src/java.base/share/classes/java/util/FormatItem.java line 597:

> 595: 
> 596:         @Override
> 597:         public long prepend(long lengthCoder, byte[] buffer) throws Throwable {

Suggestion:

        public long prepend(long lengthCoder, byte[] buffer) {

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

PR Review: https://git.openjdk.org/jdk/pull/15699#pullrequestreview-1640929916
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335047834
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335048116
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335048122
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335048144
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335048153
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335048157
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335048166
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1334053601
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335047918
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335047924
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335047939
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335047966
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335047973
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335047980
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335047986
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1335048008

From redestad at openjdk.org  Mon Oct 16 16:18:18 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Oct 2023 16:18:18 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
Message-ID: 

On Mon, 25 Sep 2023 11:36:10 GMT, Shaojin Wen  wrote:

> The reason why I split it into multiple small methods is to avoid a single method codeSize > 325. After merging small methods, the performance will decrease.

Yes, I can refactor to keep the same structure and verify performance is neutral or better. I can pick that up as a low-priority follow-up if you don't mind.

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

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1733505201

From asotona at openjdk.org  Mon Oct 16 16:18:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 16 Oct 2023 16:18:38 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v21]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 352 commits:

 - removed trailing space
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - package info javadoc improvements
 - removed obsolete exports from BuildMicrobenchmark.gmk
 - Merge branch 'master' into JDK-8308753-preview
 - added @sealedGraph tags
 - fixed exception type thrown from CodeImpl
 - added constraint to throw on an attempt to parse unknown classfile version
   + test
 - removed AttributeMapper::validSince
 - fixed DirectCodeBuilder
 - ... and 342 more: https://git.openjdk.org/jdk/compare/eb7d972d...3b36c12c

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=20
  Stats: 32095 lines in 764 files changed: 14595 ins; 14023 del; 3477 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From duke at openjdk.org  Mon Oct 16 16:18:16 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:16 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
Message-ID: <-G2c-fzLIlHQduEcYW29y5GjRbRFq5w0Gttg8WG_oHc=.5244f0ef-901a-4ec9-89ba-caf29a8f1c0f@github.com>

On Wed, 13 Sep 2023 01:24:05 GMT, Shaojin Wen  wrote:

> 1. Reduce duplicate stringSize code
> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method

@cl4es can you help me to review this PR?

private static final MethodHandle PUT_CHAR_DIGIT;

    static {
        try {
            Lookup lookup = MethodHandles.lookup();
            PUT_CHAR_DIGIT = lookup.findStatic(FormatItem.class, "putByte",
                    MethodType.methodType(void.class,
                            byte[].class, int.class, int.class));
        } catch (ReflectiveOperationException ex) {
            throw new AssertionError("putByte lookup failed", ex);
        }
    }

    private static void putByte(byte[] buffer, int index, int ch) {
        buffer[index] = (byte)ch;
    }

   int length = DecimalDigits.INSTANCE.size(value);
   DecimalDigits.INSTANCE.digits(value, this.digits, length, PUT_CHAR_DIGIT);


In the current implementation, FormatItem only calls DecimalDigits using the encoding of LATIN1

> Since the current `MethodHandle`-based char putter can only put 1-byte at once, have you considered something like this:
> 
> ```java
> // A replacement for setter MethodHandle, or VarHandle, to accept multiple value types
> public interface DigitConsumer {
>     void putChar(byte[] array, int index, byte value);
>     // put 2 byte-sized chars at once, encoded little endian
>     void putChar2(byte[] array, int index, short value);
>     // you can add putChar4, putChar8, etc. if you need
> }
> ```
> 
> and `StringConcatHelper.selectPutChar` will return a `DigitConsumer` instead of a `MethodHandle`.
> 
> Currently, you are allocating a new byte array for every number in the format, which I deem very inefficient.

Code based on MethodHandler is difficult to maintain and debug. We should remove the use of MethodHandle in FormatItem.

There are too many changes that need to be made to reduce the duplication of code in the digits method and the getCharsLatin1.

Can we temporarily allow duplicate code for digits and getCharLatin1? Revert changes related to FormatItem. After this PR is completed, submit a new PR to change FormatItem and reduce duplicate code.

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

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1717697947
PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1731821226
PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1732271564
PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1740061373

From rriggs at openjdk.org  Mon Oct 16 16:18:17 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 16 Oct 2023 16:18:17 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
Message-ID: 

On Wed, 13 Sep 2023 01:24:05 GMT, Shaojin Wen  wrote:

> 1. Reduce duplicate stringSize code
> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method

There's a lot of duplication exposed here between the `digits` method and the `getCharsLatin1` method that should be resolved. 
Can the callers of `getCharsLatin1` be converted to use `digits`?  

We also should keep HexDigits and OctalDigits classes have a consistent API and functionality.

You could benefit from compiling and testing in your repo before committing; it would cut down on the spurious changes.
and/or (before pushing) squash the intermediate commits to a single commit with a salient comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1726019081
PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1733814668

From duke at openjdk.org  Mon Oct 16 16:18:19 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:19 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
 
Message-ID: <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.5d49d50e-7538-4e52-a497-acbb8de2b142@github.com>

On Mon, 25 Sep 2023 11:46:36 GMT, Claes Redestad  wrote:

> > The reason why I split it into multiple small methods is to avoid a single method codeSize > 325. After merging small methods, the performance will decrease.
> 
> Yes, I can refactor to keep the same structure and verify performance is neutral or better. I can pick that up as a low-priority follow-up if you don't mind.

Thank you very much for your very patient review. I will be happy to see you make improvements. I see no slowdown in JMH, but I see slowdowns when I run the loop directly in the code. I am also confused. It may be that codeSize > 325 cannot be inline, which will cause some scenes to be slower.


import org.openjdk.jmh.infra.Blackhole;

public class StringFormatBench {
    public static String s = "str";
    public static int i = 17;
    public static long l = 1234567L;
    public static float f = 123.37f;

    public void complexFormat(Blackhole bh) {
        bh.consume("%3s %10d %4S %04X %4S %04X %4S %04X".formatted(s, i, s, i, s, i, s, i));
    }
}

public class StringFormatBenchTest {
   public static void complexFormat() throws Throwable {
        for (int j = 0; j < 5; j++) {
            long start = System.currentTimeMillis();
            for (int i = 0; i < 10_000_000; ++i) {
                benchmark.complexFormat(BH);
            }
            long millis = System.currentTimeMillis() - start;
            System.out.println("StringFormatBench-complexFormat millis : " + millis);
            // zulu8.58.0.13 :
            // zulu11.52.13 :
            // zulu17.38.21 :
            // jdk22-ea : 4644
            // jdk22-baseline :  16040
        }
    }

    public static void main(String[] args) throws Throwable {
        complexFormat();
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1733597301

From rgiulietti at openjdk.org  Mon Oct 16 16:18:19 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 16 Oct 2023 16:18:19 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.5d49d50e-7538-4e52-a497-acbb8de2b142@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
 
 <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.5d49d50e-7538-4e52-a497-acbb8de2b142@github.com>
Message-ID: <5kUK7lSfT934hQKZsqlY1mMJFhP6M0rBniu3h_X8i2A=.9aae2e5d-6c1c-4187-9664-c36aaeb09865@github.com>

On Mon, 25 Sep 2023 12:20:36 GMT, Shaojin Wen  wrote:

>>> The reason why I split it into multiple small methods is to avoid a single method codeSize > 325. After merging small methods, the performance will decrease.
>> 
>> Yes, I can refactor to keep the same structure and verify performance is neutral or better. I can pick that up as a low-priority follow-up if you don't mind.
>
>> > The reason why I split it into multiple small methods is to avoid a single method codeSize > 325. After merging small methods, the performance will decrease.
>> 
>> Yes, I can refactor to keep the same structure and verify performance is neutral or better. I can pick that up as a low-priority follow-up if you don't mind.
> 
> Thank you very much for your very patient review. I will be happy to see you make improvements. I see no slowdown in JMH, but I see slowdowns when I run the loop directly in the code. I am also confused. It may be that codeSize > 325 cannot be inline, which will cause some scenes to be slower.
> 
> 
> import org.openjdk.jmh.infra.Blackhole;
> 
> public class StringFormatBench {
>     public static String s = "str";
>     public static int i = 17;
>     public static long l = 1234567L;
>     public static float f = 123.37f;
> 
>     public void complexFormat(Blackhole bh) {
>         bh.consume("%3s %10d %4S %04X %4S %04X %4S %04X".formatted(s, i, s, i, s, i, s, i));
>     }
> }
> 
> public class StringFormatBenchTest {
>    public static void complexFormat() throws Throwable {
>         for (int j = 0; j < 5; j++) {
>             long start = System.currentTimeMillis();
>             for (int i = 0; i < 10_000_000; ++i) {
>                 benchmark.complexFormat(BH);
>             }
>             long millis = System.currentTimeMillis() - start;
>             System.out.println("StringFormatBench-complexFormat millis : " + millis);
>             // zulu8.58.0.13 :
>             // zulu11.52.13 :
>             // zulu17.38.21 :
>             // jdk22-ea : 4644
>             // jdk22-baseline :  16040
>         }
>     }
> 
>     public static void main(String[] args) throws Throwable {
>         complexFormat();
>     }
> }

@wenshao Can we consider the code in `FormatSpecifierParser` stable enough for a thorough review, or do you plan to make other changes there?

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

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1737325308

From duke at openjdk.org  Mon Oct 16 16:18:18 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:18 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
 
Message-ID: <1qNVgUp0u_o1hLOC4qWxrAzIAOs3hXU9X2fhIujZxiQ=.07130fd2-cb0e-4ae3-85b7-135213422681@github.com>

On Fri, 22 Sep 2023 04:46:36 GMT, Chen Liang  wrote:

> Do Octal and Hex digits need int versions of getChars and stringSize?

Since DecimalDigits made this change, for consistency, Octal and Hex digits also do the same thing.

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

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1730823316

From duke at openjdk.org  Mon Oct 16 16:18:19 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:19 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.5d49d50e-7538-4e52-a497-acbb8de2b142@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
 
 <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.5d49d50e-7538-4e52-a497-acbb8de2b142@github.com>
Message-ID: <4oceB4d7SqgewxlyuxQohj4zI3VmdJQ6EbV2DfbDeAk=.1f70e777-e980-4bb5-9b3b-0201ea4e9c1e@github.com>

On Mon, 25 Sep 2023 12:20:36 GMT, Shaojin Wen  wrote:

>>> The reason why I split it into multiple small methods is to avoid a single method codeSize > 325. After merging small methods, the performance will decrease.
>> 
>> Yes, I can refactor to keep the same structure and verify performance is neutral or better. I can pick that up as a low-priority follow-up if you don't mind.
>
>> > The reason why I split it into multiple small methods is to avoid a single method codeSize > 325. After merging small methods, the performance will decrease.
>> 
>> Yes, I can refactor to keep the same structure and verify performance is neutral or better. I can pick that up as a low-priority follow-up if you don't mind.
> 
> Thank you very much for your very patient review. I will be happy to see you make improvements. I see no slowdown in JMH, but I see slowdowns when I run the loop directly in the code. I am also confused. It may be that codeSize > 325 cannot be inline, which will cause some scenes to be slower.
> 
> 
> import org.openjdk.jmh.infra.Blackhole;
> 
> public class StringFormatBench {
>     public static String s = "str";
>     public static int i = 17;
>     public static long l = 1234567L;
>     public static float f = 123.37f;
> 
>     public void complexFormat(Blackhole bh) {
>         bh.consume("%3s %10d %4S %04X %4S %04X %4S %04X".formatted(s, i, s, i, s, i, s, i));
>     }
> }
> 
> public class StringFormatBenchTest {
>    public static void complexFormat() throws Throwable {
>         for (int j = 0; j < 5; j++) {
>             long start = System.currentTimeMillis();
>             for (int i = 0; i < 10_000_000; ++i) {
>                 benchmark.complexFormat(BH);
>             }
>             long millis = System.currentTimeMillis() - start;
>             System.out.println("StringFormatBench-complexFormat millis : " + millis);
>             // zulu8.58.0.13 :
>             // zulu11.52.13 :
>             // zulu17.38.21 :
>             // jdk22-ea : 4644
>             // jdk22-baseline :  16040
>         }
>     }
> 
>     public static void main(String[] args) throws Throwable {
>         complexFormat();
>     }
> }

> @wenshao Can we consider the code in `FormatSpecifierParser` stable enough for a thorough review, or do you plan to make other changes there?

The current Formatter tests in the test/jdk/java/util/Formatter/ directory are very complete.  I think the current version is Stable and I have no plans to make changes. I plan to continue optimizing print performance after this PR is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1737406412

From duke at openjdk.org  Mon Oct 16 16:18:18 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:18 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
 
Message-ID: 

On Tue, 19 Sep 2023 16:15:12 GMT, Roger Riggs  wrote:

> There's a lot of duplication exposed here between the `digits` method and the `getCharsLatin1` method that should be resolved. Can the callers of `getCharsLatin1` be converted to use `digits`?
> 
> We also should keep HexDigits and OctalDigits classes have a consistent API and functionality.

Changes related to FormatItem have been reverted because too many changes were made. The duplicate code of getChars and digits will be solved with another PR later.

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

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1741703218

From duke at openjdk.org  Mon Oct 16 16:18:19 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:19 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
Message-ID: <8g_CiPIfpUm-VtAw_HqB9bfaUs1ZklEGRRxo61fZv_Q=.a7db615d-1f18-4378-99c3-09249e433154@github.com>

On Wed, 27 Sep 2023 19:51:25 GMT, Raffaello Giulietti  wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> You might consider this alternative, which IMO is simpler and more readable.
> 
> 
>         int parse() {
>             // %[argument_index$][flags][width][.precision][t]conversion
>             // %(\d+$)?([-#+ 0,(<]*)?(\d+)?(.\d+)?([tT])?([a-zA-Z%])
>             parseArgument();
>             parseFlag();
>             parseWidth();
>             int precisionSize = parsePrecision();
>             if (precisionSize < 0) {
>                 return 0;
>             }
> 
>             // ([tT])?([a-zA-Z%])
>             char t = '\0', conversion = '\0';
>             if ((c == 't' || c == 'T') && off + 1 < max) {
>                 char c1 = s.charAt(off + 1);
>                 if (isConversion(c1)) {
>                     t = c;
>                     conversion = c1;
>                     off += 2;
>                 }
>             }
>             if (conversion == '\0' && isConversion(c)) {
>                 conversion = c;
>                 ++off;
>             }
> 
>             if (argSize + flagSize + widthSize + precisionSize + t + conversion != 0) {
>                 if (al != null) {
>                     FormatSpecifier formatSpecifier
>                             = new FormatSpecifier(s, start, argSize, flagSize, widthSize, precisionSize, t, conversion);
>                     al.add(formatSpecifier);
>                 }
>                 return off - start;
>             }
>             return 0;
>         }
> 
>         private void parseArgument() {
>             // (\d+$)?
>             int i = off;
>             for (; i < max && isDigit(c = s.charAt(i)); ++i);  // empty body
>             if (i == max || c != '$') {
>                 c = first;
>                 return;
>             }
>             ++i;  // skip '$'
>             if (i < max) {
>                 c = s.charAt(i);
>             }
>             argSize = i - off;
>             off = i;
>         }
> 
>         private void parseFlag() {
>             // ([-#+ 0,(<]*)?
>             int i = off;
>             for (; i < max && Flags.isFlag(c = s.charAt(i)); ++i);  // empty body
>             flagSize = i - off;
>             off = i;
>         }
> 
>         private void parseWidth() {
>             // (\d+)?
>             int i = off;
>             for (; i < max && isDigit(c = s.charAt(i)); ++i);  // empty body
>             widthSize = i - off;
>             off = i;
>         }
> 
>         private int parsePrecision() {
>             // (.\d+)?
>             if (c != '.') {
>                 return 0;
>             }
>             int i = off + 1;
>             for (; i < max && isDigit(c = s.charAt(i)); ++i);  // empty bod...

@rgiulietti @cl4es Sorry, I plan to make a change, Now there is part of the parser code in the constructor of FormatSpecifier. This is not clear. I plan to move the parser part of the constructor of FormatSpecifier into FormatSpecifierParser. This will be clearer and the performance will be faster.

* now

        FormatSpecifier(
                String s,
                int i,
                int argSize,
                int flagSize,
                int widthSize,
                int precisionSize,
                char t,
                char conversion
        ) {
            int argEnd = i + argSize;
            int flagEnd = argEnd + flagSize;
            int widthEnd = flagEnd + widthSize;
            int precesionEnd = widthEnd + precisionSize;

            if (argSize > 0) {
                index(s, i, argEnd);
            }
            if (flagSize > 0) {
                flags(s, argEnd, flagEnd);
            }
            if (widthSize > 0) {
                width(s, flagEnd, widthEnd);
            }
            if (precisionSize > 0) {
                precision(s, widthEnd, precesionEnd);
            }
            if (t != '\0') {
                dt = true;
                if (t == 'T') {
                    flags = Flags.add(flags, Flags.UPPERCASE);
                }
            }
            conversion(conversion);
            check();
        }


* plan to:

        FormatSpecifier(int index, int flags, int width, int precision, char t, char conversion) {
            if (index > 0) {
                this.index = index;
            }
            if (flags > 0) {
                this.flags = flags;
                if (Flags.contains(flags, Flags.PREVIOUS))
                    this.index = -1;
            }
            if (width > 0) {
                this.width = width;
            }
            this.precision = precision;
            if (t != '\0') {
                dt = true;
                if (t == 'T') {
                    this.flags = Flags.add(flags, Flags.UPPERCASE);
                }
            }
            conversion(conversion);
            check();
        }


FormatSpecifier will not include the functions of parser, and the functions of parser are implemented in FormatSpecifierParser.

> Meaningful external reviews take a _lot_ of engineering time on such a popular platform as the JDK.
> They make sense only on somehow stable code, otherwise they are a waste of human resources.
> 
> So sure, take your time to stabilize your code, make your tests, but please refrain from keep on changing too much once you publish a PR. If reviewers have to face continuous changes, they might become uninterested in reviewing.

@rgiulietti I have no plans to make changes, Can you help me continue the review? Thank you!

@rgiulietti can you help me continue to review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1739269749
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1747854315
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1764464777

From jlaskey at openjdk.org  Mon Oct 16 16:18:19 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 16:18:19 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 11:37:18 GMT, Chen Liang  wrote:

>> 1. Reduce duplicate stringSize code
>> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method
>
> src/java.base/share/classes/java/util/FormatItem.java line 148:
> 
>> 146:             int length = DecimalDigits.stringSize(value);
>> 147:             this.digits = new byte[length];
>> 148:             DecimalDigits.getCharsLatin1(value, length, this.digits);
> 
> Sorry missed this one in last round of review. This is wrong if you mix number fornat items and chinese segments in a String Template.

Try again (been on vacation). Not sure I agree with this refactoring. You need to account for UTF16, hence the PUT_CHAR_DIGIT. Recommend you revert and add getCharsLatin1 using the original implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1334295471

From duke at openjdk.org  Mon Oct 16 16:18:20 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 16 Oct 2023 16:18:20 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: <4iN4ROrBJbtf7HhuxP9_guULr7D3Pl344dVOPvgDpNY=.2b4a0374-648a-4fdf-98e3-21c155d64253@github.com>

On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen  wrote:

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

src/java.base/share/classes/java/util/Formatter.java line 2935:

> 2933:             for (int size = 0; off < max; c = s.charAt(++off), size++) {
> 2934:                 if (!isDigit(c)) {
> 2935:                     if (size > 0) {

I would put the first iteration outside of this loop and have a loop which doesn't need to check for it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1338342542

From duke at openjdk.org  Mon Oct 16 16:18:19 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:19 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
 
 
Message-ID: 

On Fri, 22 Sep 2023 12:09:48 GMT, Jim Laskey  wrote:

>> src/java.base/share/classes/java/util/FormatItem.java line 148:
>> 
>>> 146:             int length = DecimalDigits.stringSize(value);
>>> 147:             this.digits = new byte[length];
>>> 148:             DecimalDigits.getCharsLatin1(value, length, this.digits);
>> 
>> Sorry missed this one in last round of review. This is wrong if you mix number fornat items and chinese segments in a String Template.
>
> Try again (been on vacation). Not sure I agree with this refactoring. You need to account for UTF16, hence the PUT_CHAR_DIGIT. Recommend you revert and add getCharsLatin1 using the original implementation.

Have a great vacation! Enjoy your time off! I made a lot of changes, including removing the use of MethodHandler in FormatItem. I'm not in a hurry. You can handle the review after you come back from vacation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1334996675

From duke at openjdk.org  Mon Oct 16 16:18:21 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:21 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
Message-ID: <0e11fGG0_saPD3r-i7gy3jn1Fs5nXGUEi98r9M9NlhU=.ef92b48b-e6f1-41e0-b934-66a1e3911017@github.com>

On Mon, 25 Sep 2023 12:28:06 GMT, Claes Redestad  wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> src/java.base/share/classes/java/util/Formatter.java line 2949:
> 
>> 2947:                             }
>> 2948:                         } else {
>> 2949:                             if (first == '0') {
> 
> While it's clever to avoid re-parsing I think it muddies the control flow. It would be simpler if we always reset to `off = start; c = first` in this `else` block then unconditionally call `parseFlags(); parseWidth();` outside in `parse`. The few extra calls to `s.charAt(..)` this might add a little overhead on some tests, but the JIT might like the brevity and less branchy structure overall and on larger benchmarks.. Maybe worth experimenting with.

Good idea. In addition, I also plan to simplify the writing of the for statement, such as:

for (int size = 0; off < max; ++off, c = s.charAt(off), size++) {
==>
for (int size = 0; off < max; c = s.charAt(++off), size++) {

> src/java.base/share/classes/java/util/Formatter.java line 3420:
> 
>> 3418:                     && fmt.a instanceof StringBuilder sb
>> 3419:             ) {
>> 3420:                 sb.append(value);
> 
> There's a lot of `if`s here, and this doesn't take into account locales with non-ASCII digits:
> 
> Locale ar = new Locale.Builder().setLanguageTag("ar-SA-u-nu-arab").build();
> Locale.setDefault(ar);
> System.out.println("%d".formatted(10000)); // should print "?????" but prints "10000"

The change code of print fast-path has been deleted, and parse fast-path has added support for the pattern "%8.3f".

Where to draw the line of parse fast-path? I have seen patterns that cause performance problems, and they can be easily implemented, so I added them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335909991
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1328178751

From duke at openjdk.org  Mon Oct 16 16:18:21 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:21 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <0e11fGG0_saPD3r-i7gy3jn1Fs5nXGUEi98r9M9NlhU=.ef92b48b-e6f1-41e0-b934-66a1e3911017@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
 <0e11fGG0_saPD3r-i7gy3jn1Fs5nXGUEi98r9M9NlhU=.ef92b48b-e6f1-41e0-b934-66a1e3911017@github.com>
Message-ID: 

On Mon, 18 Sep 2023 00:48:26 GMT, Shaojin Wen  wrote:

>> src/java.base/share/classes/java/util/Formatter.java line 3420:
>> 
>>> 3418:                     && fmt.a instanceof StringBuilder sb
>>> 3419:             ) {
>>> 3420:                 sb.append(value);
>> 
>> There's a lot of `if`s here, and this doesn't take into account locales with non-ASCII digits:
>> 
>> Locale ar = new Locale.Builder().setLanguageTag("ar-SA-u-nu-arab").build();
>> Locale.setDefault(ar);
>> System.out.println("%d".formatted(10000)); // should print "?????" but prints "10000"
>
> The change code of print fast-path has been deleted, and parse fast-path has added support for the pattern "%8.3f".
> 
> Where to draw the line of parse fast-path? I have seen patterns that cause performance problems, and they can be easily implemented, so I added them.

Now parse fast-path supports "8.3f", but not "10.3". Because the fast-path method code size should be less than 325, for JIT inline

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1328210418

From duke at openjdk.org  Mon Oct 16 16:18:20 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Mon, 16 Oct 2023 16:18:20 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
Message-ID: 

On Wed, 13 Sep 2023 01:24:05 GMT, Shaojin Wen  wrote:

> 1. Reduce duplicate stringSize code
> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 115:

> 113:         }
> 114:         return 10 + d;
> 115:     }

@wenshao How about of using [this](https://github.com/plokhotnyuk/jsoniter-scala/blob/6b72cf75ad7f53e8a285d512009d164c3eabbb3a/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L2367-L2369) trick to avoid multiplications in a loop?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1334280362

From duke at openjdk.org  Mon Oct 16 16:18:20 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 16:18:20 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 11:53:18 GMT, Andriy Plokhotnyuk  wrote:

>> 1. Reduce duplicate stringSize code
>> 2. Move java.lang.StringLatin1.getChars to jdk.internal.util.DecimalDigits::getCharLatin1?not only java.lang, other packages also need to use this method
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 115:
> 
>> 113:         }
>> 114:         return 10 + d;
>> 115:     }
> 
> @wenshao How about of using [this](https://github.com/plokhotnyuk/jsoniter-scala/blob/6b72cf75ad7f53e8a285d512009d164c3eabbb3a/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L2367-L2369) trick to avoid multiplications in a loop?

This implementation is copied from Integer.stringSize. In 2015, @Shipilev modified the table lookup to the current implementation. In actual testing, this algorithm is faster.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1334411468

From redestad at openjdk.org  Mon Oct 16 16:18:21 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 16 Oct 2023 16:18:21 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
 <0e11fGG0_saPD3r-i7gy3jn1Fs5nXGUEi98r9M9NlhU=.ef92b48b-e6f1-41e0-b934-66a1e3911017@github.com>
 
Message-ID: 

On Mon, 18 Sep 2023 02:59:06 GMT, Shaojin Wen  wrote:

>> The change code of print fast-path has been deleted, and parse fast-path has added support for the pattern "%8.3f".
>> 
>> Where to draw the line of parse fast-path? I have seen patterns that cause performance problems, and they can be easily implemented, so I added them.
>
> Now parse fast-path supports "8.3f", but not "10.3". Because the fast-path method code size should be less than 325, for JIT inline

What I meant is that theoretically we *could* drop the regex code entirely and write a custom parser that specializes every formatter, but that we probably *shouldn't* as this means duplicating a lot of code and we'd likely end up having to maintain both. Exactly which patterns to specialize for is an open question. `"%8.3f"` is common, sure, but so are specifiers like `"%-6d"`. I think it'd be good if we could collect some stats on which specifier patterns are the most common rather than just picking a few at random. 

I see you added a microbenchmark for yet another happy case, which sort of misses my point about setting micros up to explore the boundaries: the set of microbenchmarks should ideally explore and verify both fast-paths and slow-paths, to show that the benefit of the former is significant while the overhead added to the slow-path is negligible. Adding a `floatFormat2` that does `return "%1.12f".formatted...`, as an example: 


Name                      Cnt    Base   Error     Test   Error  Unit   Diff%
StringFormat.floatFormat   15 316,133 ? 7,890  170,958 ? 8,231 ns/op   45,9% (p = 0,000*)
StringFormat.floatFormat2  15 342,767 ? 4,721  343,748 ? 3,753 ns/op   -0,3% (p = 0,506 )
  * = significant


This verifies that the added overhead is in the noise when the fast-path fail on this test.

We don't need to cover every possibility and have an ever-growing set of micros that all just test the fast-path, so I think you can remove the additions and instead adjust one or two of the existing microbenchmarks so that it verifies the slow-path with your PR applied.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1328460325

From jlaskey at openjdk.org  Mon Oct 16 16:18:20 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 16:18:20 GMT
Subject: RFR: 8316150: Refactor get chars and string size
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.91666616-d2f5-4fa4-8cc9-fb2d82d79f25@github.com>
 
 
Message-ID: 

On Fri, 22 Sep 2023 13:50:37 GMT, Shaojin Wen  wrote:

>> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 115:
>> 
>>> 113:         }
>>> 114:         return 10 + d;
>>> 115:     }
>> 
>> @wenshao How about of using [this](https://github.com/plokhotnyuk/jsoniter-scala/blob/6b72cf75ad7f53e8a285d512009d164c3eabbb3a/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L2367-L2369) trick to avoid multiplications in a loop?
>
> This implementation is copied from Integer.stringSize. In 2015, @Shipilev modified the table lookup to the current implementation. In actual testing, this algorithm is faster.

No doubt, but that algorithm could have been easily integrated into the Digits implementation without disruption.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1334490412

From iris at openjdk.org  Mon Oct 16 16:18:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 16 Oct 2023 16:18:21 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: 

On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen  wrote:

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

test/jdk/java/util/Formatter/BasicInt.java line 404:

> 402: 
> 403:         // non-conversion
> 404:         tryCatch("%12", UnknownFormatConversionException.class);

Is this file still mechanically generated as indicated in line 31 (above)?  Perhaps these changes should be in Basic-X.java.template instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1350397453

From aturbanov at openjdk.org  Mon Oct 16 16:18:22 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 16 Oct 2023 16:18:22 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: 

On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen  wrote:

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

test/micro/org/openjdk/bench/java/lang/StringFormat.java line 51:

> 49:     public String s = "str";
> 50:     public int i = 17;
> 51:     public static final BigDecimal pi  = new BigDecimal(Math.PI);

Suggestion:

    public static final BigDecimal pi = new BigDecimal(Math.PI);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1338299849

From jlaskey at openjdk.org  Mon Oct 16 16:20:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 16:20:12 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v2]
In-Reply-To: 
References: 
Message-ID: 

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Revert source
 - Revert @since 22

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/b95c799e..f077ef6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=00-01

  Stats: 26 lines in 19 files changed: 0 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

PR: https://git.openjdk.org/jdk/pull/16202

From jlahoda at openjdk.org  Mon Oct 16 16:20:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 16 Oct 2023 16:20:24 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 15:23:25 GMT, Jim Laskey  wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert source
>  - Revert @since 22

javac changes look reasonable to me. Added some mostly minor comments.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1691:

> 1689:         }
> 1690: 
> 1691:         private Type getProcessMethodType(JCStringTemplate tree, Type processorType) {

This method is basically the same as in `Attr`, correct? I wonder if there's a way to avoid the duplication? One possibility would be to compute the type in `Attr`, and store it in a field on `JCStringTemplate`, and just use it in `Flow`. Alternatively, it could be shared in some class, although only `TreeInfo` and `Resolve` come to mind, and neither seem particularly suitable for that.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 257:

> 255: 
> 256:         boolean isNamedProcessor(Name name) {
> 257:             Symbol sym = switch (processor) {

Maybe `TreeInfo.symbol(processor)` here?

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

PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1680264976
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360841404
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360830232

From mdoerr at openjdk.org  Mon Oct 16 16:20:49 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Oct 2023 16:20:49 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v4]
In-Reply-To: 
References: 
Message-ID: 

> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to PlatformLayouts.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16179/files
  - new: https://git.openjdk.org/jdk/pull/16179/files/cba58ed0..17b300ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16179&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16179&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16179/head:pull/16179

PR: https://git.openjdk.org/jdk/pull/16179

From mdoerr at openjdk.org  Mon Oct 16 16:21:08 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Oct 2023 16:21:08 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 14:06:09 GMT, Martin Doerr  wrote:

>> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support 4-byte aligned doubles in structures.

I have reverted the changes in PlatformLayouts.java. We use 8-byte aligned double by default, now. I have filed a subtask to handle the tests: https://bugs.openjdk.org/browse/JDK-8318175
This PR is now compatible with "#pragma align (natural)", but permits layouts according to the default setting. This allows writing Java code which calls any library which was built with either option. The developer needs to know which layout to use. (I guess it will be a very rare issue.)
Changes related to how we handle object layouts could still be done by IBM in follow-up issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/16179#issuecomment-1764790140

From mcimadamore at openjdk.org  Mon Oct 16 16:32:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Oct 2023 16:32:58 GMT
Subject: RFR: 8318180: Memory model reference from foreign package-info is
 broken
Message-ID: 

This PR fixes a wrong reference to the JLS memory model section.

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

Commit messages:
 - Initial push

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

PR: https://git.openjdk.org/jdk/pull/16204

From bpb at openjdk.org  Mon Oct 16 16:34:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Oct 2023 16:34:20 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v7]
In-Reply-To: <26zgN9543IcbQEum-nEsgfSv4v8412UkkJ412GszuXw=.44fa0b44-fc17-40d0-99a6-87d6d8be58a1@github.com>
References: 
 <26zgN9543IcbQEum-nEsgfSv4v8412UkkJ412GszuXw=.44fa0b44-fc17-40d0-99a6-87d6d8be58a1@github.com>
Message-ID: 

On Wed, 4 Oct 2023 20:35:25 GMT, Brian Burkhalter  wrote:

>> In the Windows implementation of java.io.File.getCanonicalPath, strip any long path or UNC prefix before canonicalizing the remainder of the pathname.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287843: Remove unused constant and method from WindowsPrefixes test

The CSR was created.

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

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1764854977

From egahlin at openjdk.org  Mon Oct 16 16:40:52 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 16 Oct 2023 16:40:52 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 15 Oct 2023 23:46:45 GMT, Chen Liang  wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Blessed order
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 227:
> 
>> 225:         for (MethodModel m : classModel.methods()) {
>> 226:             for (MethodElement me : m.elements()) {
>> 227:                 if (me instanceof RuntimeVisibleAnnotationsAttribute rvaa) {
> 
> Same remark, `m.findAttribute(Attributes.RUNTIME_VISIBLE_ANNOTATIONS)`

See above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16195#discussion_r1360947552

From jlaskey at openjdk.org  Mon Oct 16 16:54:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 16:54:13 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 16 Oct 2023 15:17:10 GMT, Jan Lahoda  wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert source
>>  - Revert @since 22
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1691:
> 
>> 1689:         }
>> 1690: 
>> 1691:         private Type getProcessMethodType(JCStringTemplate tree, Type processorType) {
> 
> This method is basically the same as in `Attr`, correct? I wonder if there's a way to avoid the duplication? One possibility would be to compute the type in `Attr`, and store it in a field on `JCStringTemplate`, and just use it in `Flow`. Alternatively, it could be shared in some class, although only `TreeInfo` and `Resolve` come to mind, and neither seem particularly suitable for that.

I thought of the TreeInfo and Resolve idea but the number of arguments required made it messy. Hanging off of JCStringTemplate seemed like clutter to me.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 257:
> 
>> 255: 
>> 256:         boolean isNamedProcessor(Name name) {
>> 257:             Symbol sym = switch (processor) {
> 
> Maybe `TreeInfo.symbol(processor)` here?

Only want to allow JCIdent and and JCFieldAcesss. Other expressions can't produce the STR/RAW symbols, but ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360965274
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360962420

From mcimadamore at openjdk.org  Mon Oct 16 16:59:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 16 Oct 2023 16:59:46 GMT
Subject: RFR: 8318180: Memory model reference from foreign package-info is
 broken
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 16:19:41 GMT, Maurizio Cimadamore  wrote:

> This PR fixes a wrong reference to the JLS memory model section.

The broken reference seems to have originated from a bogus [edit](https://github.com/openjdk/panama-foreign/pull/751/files/4c4928d6c891132face4b78e702bbb611f6a67a3..4661d30bc0aae3fa7c58792eb7545bea0b3da527) to a section that used to be present:


* @apiNote The normal Java Object access control, guarantees and constraints, for example stated in
 * {@jls 6.6} and {@jls 10.4}, do not apply when accessing native memory segments as these segments are
 * backed by off-heap regions of memory.
 ```

Accidentally, ` normal Java Object access control, guarantees and constraints,` was replaced to reference memory model (following a CSR comment). But the old JLS reference stayed, leading to this issue.

We could, if desired, also keep the old references (and text!) too - but IMHO it is a bit confusing to be talking about access control when mentioning access to off-heap memory, so maybe it would be better to leave those out?

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

PR Comment: https://git.openjdk.org/jdk/pull/16204#issuecomment-1764895796

From mdonovan at openjdk.org  Mon Oct 16 17:01:20 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 16 Oct 2023 17:01:20 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  retained a reference to the RMI server and improved naming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14932/files
  - new: https://git.openjdk.org/jdk/pull/14932/files/35c0a881..0df1071e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14932&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14932&range=01-02

  Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14932/head:pull/14932

PR: https://git.openjdk.org/jdk/pull/14932

From mdoerr at openjdk.org  Mon Oct 16 17:21:28 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Oct 2023 17:21:28 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v4]
In-Reply-To: 
References: 
 
 <6YT12R_oTlgqEszL3oyyMYQY-hHVheTp2zB05BiOhu4=.6092f7bb-bf57-413f-99da-75dc7ed8eb95@github.com>
 
 
 
 <1e0UKjLki9CKGnkYZlQ5Er_Dml7brWXSNMafVcnBwEU=.bc27228d-b909-4704-9ada-f0e53be69599@github.com>
 
 
 
 
 
 
 
Message-ID: 

On Mon, 16 Oct 2023 14:41:40 GMT, Maurizio Cimadamore  wrote:

>> Please take a look at commit number 4. I think we need to support both, 4-byte and 8-byte aligned doubles in structures. IBM recommends to use "#pragma align (natural)": "The power suboption is the default to ensure compatibility with existing objects. If compatibility with earlier versions is not necessary, you should consider using natural alignment to improve potential application performance." https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.1?topic=pragmas-pragma-align
>> We could also recommend to use "#pragma align (natural)" for the FFI (and possibly for tests). That would reduce incompatibility with other platforms. I can file a subtask for test adaptation if needed.
>
> Hi @TheRealMDoerr - yes, last weekend I read some bits from the AIX ABI, and it does seem that the more optimized variant is the "natural" variant, as that respects data alignment. As you write "power" seems to be the default, out of some compatibility constraints. But I think the main point that Jorn and I are trying to make is that the fact that "power" behaves in the way it does (e.g. it aligns all double fields after the first one at 4 bytes, rather than 8) has nothing to do with the intrinsic alignment of a double in AIX. E.g. the `double` type in AIX has alignment 8 (and you can check that using `alignof`). Then, it seems like all structs in AIX are compiled as if by using a pack pragma - and _that_ is what causes some double fields to feature a more packed alignment constraints.
> 
> Where does this leave us? There are few options:
> 
> * As you say, one option would be to just say that on AIX we only support the "natural" variant. This is similar to what we do on other platforms, where we do not support passing packed structs to functions (and what the javadoc of Linker says).
> * Another option is to relax the Linker javadoc so that struct layouts are completely Linker specific. This would allow the AIX linker to support whatever alignment is requested.
> 
> I have very little experience with AIX, so I'm not in a position to say how much the first option would be perceived as a restriction or not. The nice thing about the first option is that clients of FFM do not have to worry about structs in AIX having special rules. But, perhaps that's an unrealistic goal anyway, and I can imagine other ABIs also going down the path of specifying various packed representations which are not supported by the current javadoc text.
> 
> Perhaps, from a logistical point of view, starting off with "natural" for now, and then relaxing the documentation later, and add support for packed structs, would be better, as the changes would be more localized.

I don't think we can afford rejecting the default variant. But we can state that we only use and test the "natural" variant internally. That will keep most of the trouble away from us, but still require the javadoc change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1361011164

From abimpoudis at openjdk.org  Mon Oct 16 17:25:27 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 17:25:27 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v20]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Address review
   
   - Add comments
   - Rename exactness methods
   - Use convenience methods from TypeTag for checkUnconditionallyExactPrimitives in Types
   - Port isStrictSubRangeOf to Wrapper and use it for unconditionalExactnessCheck in SwitchBootstraps
 - Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
 - Merge branch 'master' into primitive-patterns
 - Update name of exactness methods class
 - Merge branch 'master' into primitive-patterns
 - Adjust tests
   
   Co-authored-by: Jan Lahoda 
   Co-authored-by: Angelos Bimpoudis 
 - Fix exhaustiveness check for primitive types
 - Add tests
 - Improve non integral check
 - ... and 16 more: https://git.openjdk.org/jdk/compare/f1f3e73c...2f03b1b9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/d06b2172..2f03b1b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=18-19

  Stats: 12908 lines in 521 files changed: 8067 ins; 2451 del; 2390 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Mon Oct 16 17:25:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 17:25:29 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
 
Message-ID: <2hItDawsZ_qmMOTOQeLP81XQu1O0A3yyTGG_5xKACXA=.b3a4642d-7ca3-4675-8dc6-05d749bb2e73@github.com>

On Fri, 13 Oct 2023 09:33:28 GMT, Raffaello Giulietti  wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
>
> src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 51:
> 
>> 49:      *
>> 50:      * */
>> 51:     public static boolean intToByteExact(int n)      {return n == (int)(byte)n;}
> 
> These ones seem more _conversions_ than _tests_.
> To me, `intToByteExact(int)` looks more like a request to convert an `int` to a `byte`, rather than a check to see whether the argument lies in the `byte` range.
> Pure methods returning `boolean` are often named like `isIntToByteExact(int)` or the like (`is*()`, `has*()`, etc.)
> 
> I know: choosing good, speaking, and evocative names is one of the hardest problem in computer science.

Good recommendation. Names updated!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1361013093

From abimpoudis at openjdk.org  Mon Oct 16 17:25:34 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 17:25:34 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
 
Message-ID: 

On Thu, 12 Oct 2023 20:42:50 GMT, Vicente Romero  wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 366:
> 
>> 364:             (selectorType.equals(int.class) && targetType.equals(Integer.class)))
>> 365:             return true;
>> 366:         else if (selectorType.equals(targetType) || (selectorType.equals(byte.class) && !targetType.equals(char.class)  ||
> 
> this code reminds me of some tricks we did to simplify similar code in the past, see `com.sun.tools.javac.code.TypeTag` and related:  `com.sun.tools.javac.code.TypeTag.NumericClasses` and method `com.sun.tools.javac.code.TypeTag::isSubRangeOf` and how it is used to determine if a numerical type is subtype of another numerical type. These tricks could be reused here, but up to you. I could also be done in a future refactoring.

Thanks for the recommendation. I used them and ported the subrange functionality to Wrappers (added two extra parameters for the enum variants).

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5055:
> 
>> 5053:         return (source.isPrimitive() && target.isPrimitive()) &&
>> 5054:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||
>> 5055:                         (source.hasTag(SHORT) && (target.hasTag(INT) || target.hasTag(LONG) || target.hasTag(FLOAT) || target.hasTag(DOUBLE)))||
> 
> this code can also be simplified as suggested for similar code in SwitchBootstraps, actually here you have access to the infra already in TypeTag and can leverage it.

Done.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2910:
> 
>> 2908:     }
>> 2909: 
>> 2910:     public void visitTypeTest(JCInstanceOf tree) {
> 
> would it make sense to document how the generated code should look like?

Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1361010084
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1361013492
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1361010752

From asemenyuk at openjdk.org  Mon Oct 16 17:26:58 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 16 Oct 2023 17:26:58 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 03:32:55 GMT, yaqsun  wrote:

> on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
> It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
> But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.

`%define _build_id_links none` must be added to a spec file in LinuxResourceTest.java file. not on `rpmbuild` command line

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

PR Comment: https://git.openjdk.org/jdk/pull/15832#issuecomment-1764937856

From abimpoudis at openjdk.org  Mon Oct 16 18:02:22 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 18:02:22 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR finalizes the feature of unnamed variables and patterns.

Aggelos Biboudis has updated the pull request with a new target base 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 unnamed
 - Add test with multi-catch
 - Merge branch 'master' into unnamed
 - Address review by @mcimadamore
 - Address review by @lahodaj
 - 8315532: Compiler Implementation for Unnamed Variables and Patterns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/ccbfbd4f..13a4b6f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=03-04

  Stats: 12707 lines in 528 files changed: 7998 ins; 2437 del; 2272 mod
  Patch: https://git.openjdk.org/jdk/pull/15649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649

PR: https://git.openjdk.org/jdk/pull/15649

From msheppar at openjdk.org  Mon Oct 16 18:30:51 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 16 Oct 2023 18:30:51 GMT
Subject: RFR: JDK-8249832:
 java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id [v3]
In-Reply-To: 
References: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
 
Message-ID: 

On Fri, 13 Oct 2023 12:18:53 GMT, Agnibho Hom Chowdhury  wrote:

>> Please review this PR as a fix of [JDK-8249832](https://bugs.openjdk.org/browse/JDK-8249832). I have added the bug with after @ignore annotation.
>
> Agnibho Hom Chowdhury has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted copyright year update

Marked as reviewed by msheppar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16073#pullrequestreview-1680714528

From abimpoudis at openjdk.org  Mon Oct 16 19:16:41 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 19:16:41 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v21]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <8yU_xOd6jajN9pJ2Hjvs-ye4BV2hbnMlyVmxP_CqL-0=.08fab3e6-4cd1-4f72-801e-2c2d2210ce9e@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Adjust javadoc on ExactConversionsSupport

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/2f03b1b9..ac0b6782

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=19-20

  Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From jvernee at openjdk.org  Mon Oct 16 19:27:48 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 16 Oct 2023 19:27:48 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 16 Oct 2023 15:54:12 GMT, Martin Doerr  wrote:

> I have filed a subtask to handle the tests: https://bugs.openjdk.org/browse/JDK-8318175 This PR is now compatible with "#pragma align (natural)", but permits layouts according to the default setting. This allows writing Java code which calls any library which was built with either option.

Supporting both seems like the best solution to me. The spec of Linker will need to be updated to allow for the packed variant as well.

> The developer needs to know which layout to use. (I guess it will be a very rare issue.) 

This seems fine to me. For linking in general, the developer is already expected to know what the right descriptor is. We try to do as much checking as possible to look for descriptors that don't make sense, or which the CallArrangers do not support (hence packed structs are currently rejected), but we can not check everything.

>  Changes related to how we handle object layouts could still be done by IBM in follow-up issues.

Ok. I'm assuming there are currently some failing tests due to the mismatch in ABI? (assuming the test libraries are compiled for the packed ABI)

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

PR Comment: https://git.openjdk.org/jdk/pull/16179#issuecomment-1765135912

From naoto at openjdk.org  Mon Oct 16 20:14:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Oct 2023 20:14:08 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR locale
 provider
Message-ID: 

CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

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

Commit messages:
 - tidy up
 - substitute letters
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/16206/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16206&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317979
  Stats: 162 lines in 6 files changed: 139 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/16206.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16206/head:pull/16206

PR: https://git.openjdk.org/jdk/pull/16206

From jvernee at openjdk.org  Mon Oct 16 20:30:13 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 16 Oct 2023 20:30:13 GMT
Subject: RFR: 8318180: Memory model reference from foreign package-info is
 broken
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 16:57:04 GMT, Maurizio Cimadamore  wrote:

> We could, if desired, also keep the old references (and text!) too - but IMHO it is a bit confusing to be talking about access control when mentioning access to off-heap memory, so maybe it would be better to leave those out?

I don't see how a reference to access control would be useful here. Leave it out, IMO.

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

PR Comment: https://git.openjdk.org/jdk/pull/16204#issuecomment-1765206893

From jvernee at openjdk.org  Mon Oct 16 20:30:08 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 16 Oct 2023 20:30:08 GMT
Subject: RFR: 8318180: Memory model reference from foreign package-info is
 broken
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 16:19:41 GMT, Maurizio Cimadamore  wrote:

> This PR fixes a wrong reference to the JLS memory model section.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16204#pullrequestreview-1680886449

From naoto at openjdk.org  Mon Oct 16 20:39:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Oct 2023 20:39:26 GMT
Subject: RFR: 8317742: ISO Standard Date Format implementation consistency
 on DateTimeFormatter and String.format [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 9 Oct 2023 23:21:57 GMT, Shaojin Wen  wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No longer localize printed numbers

src/java.base/share/classes/java/util/Formatter.java line 4492:

> 4490:                 }
> 4491:                 case DateTime.ISO_STANDARD_DATE: { // 'F' (%Y-%m-%d)
> 4492:                     // ISO_STANDAR_DTE does not need to deal with Locale

typo

test/jdk/java/util/Formatter/BasicDateTime.java line 473:

> 471:                 Locale.forLanguageTag("th-TH-u-nu-thai"));
> 472:         test("%tF", "2023-01-13", LocalDate.of(2023, 1, 13));
> 473:         Locale.setDefault(locale);

This is an incompatible change. If you intend to change the behavior, this should be approved in the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1361238189
PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1361238558

From duke at openjdk.org  Mon Oct 16 20:50:45 2023
From: duke at openjdk.org (Agnibho Hom Chowdhury)
Date: Mon, 16 Oct 2023 20:50:45 GMT
Subject: RFR: JDK-8249832:
 java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id [v4]
In-Reply-To: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
References: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
Message-ID: 

> Please review this PR as a fix of [JDK-8249832](https://bugs.openjdk.org/browse/JDK-8249832). I have added the bug with after @ignore annotation.

Agnibho Hom Chowdhury has updated the pull request incrementally with one additional commit since the last revision:

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16073/files
  - new: https://git.openjdk.org/jdk/pull/16073/files/da9e5edc..8191bc58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16073&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16073&range=02-03

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16073.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16073/head:pull/16073

PR: https://git.openjdk.org/jdk/pull/16073

From duke at openjdk.org  Mon Oct 16 20:52:10 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 20:52:10 GMT
Subject: RFR: 8317742: ISO Standard Date Format implementation consistency
 on DateTimeFormatter and String.format [v3]
In-Reply-To: 
References: 
Message-ID: 

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/d90111f8..8b31e875

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16033/head:pull/16033

PR: https://git.openjdk.org/jdk/pull/16033

From duke at openjdk.org  Mon Oct 16 20:54:29 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 20:54:29 GMT
Subject: RFR: 8317742: ISO Standard Date Format implementation consistency
 on DateTimeFormatter and String.format [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 16 Oct 2023 20:36:42 GMT, Naoto Sato  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No longer localize printed numbers
>
> test/jdk/java/util/Formatter/BasicDateTime.java line 473:
> 
>> 471:                 Locale.forLanguageTag("th-TH-u-nu-thai"));
>> 472:         test("%tF", "2023-01-13", LocalDate.of(2023, 1, 13));
>> 473:         Locale.setDefault(locale);
> 
> This is an incompatible change. If you intend to change the behavior, this should be approved in the CSR.

Yes, the incompatibility information described in the CSR above also covers this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1361250989

From igavrilin at openjdk.org  Mon Oct 16 21:14:39 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Mon, 16 Oct 2023 21:14:39 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
> 
> Tests:
> Performance tests on t-head board:
> With intrinsics:
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
> 
> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
> 
> Regression tests: tier1, hotspot:tier2 on risc-v board.
> 
> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
> 
> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> index 6cd1353907e..0bee25366bf 100644
> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>  
>      @Benchmark
>      public double  copySignDouble() {
> -        return  Math.copySign(double81, doubleNegative12);
> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>      }
>  
>      @Benchmark
>      public float  copySignFloat() {
> -        return  Math.copySign(floatNegative99, float1);
> +        return  Math.copySign(floatNegative99, float1) + Math.copySign(eFloat, float1) + Math.copySign...

Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:

  Fix some registers usages and typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16186/files
  - new: https://git.openjdk.org/jdk/pull/16186/files/6939eff8..b0a53a0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=00-01

  Stats: 14 lines in 3 files changed: 1 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16186/head:pull/16186

PR: https://git.openjdk.org/jdk/pull/16186

From dholmes at openjdk.org  Mon Oct 16 21:17:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Oct 2023 21:17:30 GMT
Subject: RFR: 8318126: Refresh manpages
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 06:02:02 GMT, Alan Bateman  wrote:

>> The open nroff manpage files are out of sync with their closed markdown sources and need to be refreshed.
>> 
>> The changes to apply are coming from:
>> 
>> - [JDK-8288158](https://bugs.openjdk.org/browse/JDK-8288158): Add an anchor to each subcommand option on jfr html page
>> - [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>> - [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
>> - [JDK-8308662](https://bugs.openjdk.org/browse/JDK-8308662): Update the "java" tool specification for CompileOnly
>> - [JDK-8317565](https://bugs.openjdk.org/browse/JDK-8317565): Update Manpage for obsoletion of UseSHM
>> - [JDK-8310460](https://bugs.openjdk.org/browse/JDK-8310460): Remove jdeps -profile option
>> 
>> There are also some simple line break changes, likely due to using different versions of the pandoc tool.
>> 
>> Thanks
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the reviews @AlanBateman and @Hamlin-Li

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

PR Comment: https://git.openjdk.org/jdk/pull/16196#issuecomment-1765289558

From bpb at openjdk.org  Mon Oct 16 21:40:21 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Oct 2023 21:40:21 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 21:55:24 GMT, Brian Burkhalter  wrote:

>> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274122: Make value of exceptionExpected more robust to Windows version

I am not sure what else could be done here. Does anyone have any suggestions? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/15460#issuecomment-1765318832

From mdoerr at openjdk.org  Mon Oct 16 21:41:21 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Oct 2023 21:41:21 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 16 Oct 2023 19:24:51 GMT, Jorn Vernee  wrote:

> Ok. I'm assuming there are currently some failing tests due to the mismatch in ABI? (assuming the test libraries are compiled for the packed ABI)

We should be careful with the names:

- "#pragma align (power)" is the default which is currently used to compile the test libraries and which uses 4-byte alignment for double in structs after first member. It's compatible with libraries which were built with default settings.
- "#pragma align (packed)" is a special mode which packs even more, but I don't think we need to support that.
- "#pragma align (natural)" is the one which makes the layout compatible with other platforms and which is recommended for performance.

Almost all of the jdk/java/foreign are currently failing because of https://bugs.openjdk.org/browse/JDK-8317799. Suchi has a preliminary fix and with that most tests have passed with the 4-byte aligned double members. Almost all tests should work after both subtasks are resolved. (There are still a couple of things to investigate which are not related to Up-/Downcalls.)
My standalone tests are working fine with this PR. I've tried both, changing the layout to 4-byte double alignment and "#pragma align (natural)".

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

PR Comment: https://git.openjdk.org/jdk/pull/16179#issuecomment-1765319281

From duke at openjdk.org  Mon Oct 16 22:33:26 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 22:33:26 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl does
 not throw CharacterCodingException
Message-ID: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>

When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

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

Commit messages:
 - Make the NoRepl methods throw IllegalArgument

Changes: https://git.openjdk.org/jdk/pull/16209/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318200
  Stats: 93 lines in 8 files changed: 10 ins; 58 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/16209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209

PR: https://git.openjdk.org/jdk/pull/16209

From jvernee at openjdk.org  Mon Oct 16 22:59:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 16 Oct 2023 22:59:22 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 16:20:49 GMT, Martin Doerr  wrote:

>> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to PlatformLayouts.java

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java line 64:

> 62:         // Note: It is possible to enforce 8-byte alignment by #pragma align (natural)
> 63:         // Therefore, we use normal checks if we are already 8-byte aligned.
> 64:         if ((offset % 8 != 0) && (member instanceof ValueLayout vl && vl.carrier() == double.class)) {

I think you should check for the correct byte order as well at some point, for this special case

test/micro/org/openjdk/bench/java/lang/foreign/pointers/NativeType.java line 61:

> 59:         @Override
> 60:         public ValueLayout.OfInt layout() {
> 61:             return (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int");

For this benchmark, we rely on constant folding through these layouts. So, we shouldn't go through `canonicalLayouts` here. We can store the layout in a `static final` field, and then return it here instead.

test/micro/org/openjdk/bench/java/lang/foreign/pointers/NativeType.java line 68:

> 66:         @Override
> 67:         public ValueLayout.OfDouble layout() {
> 68:             return (ValueLayout.OfDouble) LINKER.canonicalLayouts().get("double");

Same here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1361340368
PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1361338651
PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1361338681

From vdyakov at openjdk.org  Mon Oct 16 23:29:17 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Mon, 16 Oct 2023 23:29:17 GMT
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 22:15:00 GMT, Alexander Matveev  wrote:

> - Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
> - If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
>> Error: "codesign" failed with following output:
>> test: no identity found
> 
>> Error: "productbuild" failed with following output:
>> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
> - Added error handling not to allow invalid combinations of signing options.
> - Updated signing tests to test new changes.

@alexeysemenyukoracle please review

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

PR Comment: https://git.openjdk.org/jdk/pull/16085#issuecomment-1765420130

From naoto at openjdk.org  Mon Oct 16 23:37:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Oct 2023 23:37:51 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v2]
In-Reply-To: 
References: 
Message-ID: 

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Use ZoneOffset to parse offset

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16206/files
  - new: https://git.openjdk.org/jdk/pull/16206/files/d38c58a5..3d221558

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16206&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16206&range=00-01

  Stats: 10 lines in 1 file changed: 1 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16206.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16206/head:pull/16206

PR: https://git.openjdk.org/jdk/pull/16206

From iris at openjdk.org  Mon Oct 16 23:57:19 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 16 Oct 2023 23:57:19 GMT
Subject: RFR: 8318126: Refresh manpages
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 01:18:52 GMT, David Holmes  wrote:

> The open nroff manpage files are out of sync with their closed markdown sources and need to be refreshed.
> 
> The changes to apply are coming from:
> 
> - [JDK-8288158](https://bugs.openjdk.org/browse/JDK-8288158): Add an anchor to each subcommand option on jfr html page
> - [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> - [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> - [JDK-8308662](https://bugs.openjdk.org/browse/JDK-8308662): Update the "java" tool specification for CompileOnly
> - [JDK-8317565](https://bugs.openjdk.org/browse/JDK-8317565): Update Manpage for obsoletion of UseSHM
> - [JDK-8310460](https://bugs.openjdk.org/browse/JDK-8310460): Remove jdeps -profile option
> 
> There are also some simple line break changes, likely due to using different versions of the pandoc tool.
> 
> Thanks

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16196#pullrequestreview-1681114738

From smarks at openjdk.org  Tue Oct 17 00:07:25 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 17 Oct 2023 00:07:25 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 17:01:20 GMT, Matthew Donovan  wrote:

>> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retained a reference to the RMI server and improved naming

Nice cleanups here. I think investing a bit in the test library will be very helpful. It certainly improves this test, and it opens the possibility of cleaning up other tests as well.

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 81:

> 79:                 0, new SslRMIClientSocketFactory(), serverSocketFactory);
> 80:         HelloClient client = new HelloClient();
> 81:         client.runClient(stub);

You could even inline HelloClient here, as I don't think that having a separate class is actually doing anything..

test/lib/jdk/test/lib/Asserts.java line 575:

> 573:      * @return The thrown exception.
> 574:      */
> 575:     public static Exception assertThrownException(Class expected, TestMethod testMethod) {

Cool, this is a good addition to the test library, to enable tests to use this style of assertion over testing without having to include JUnit or something. Here I would copy JUnit's `expectThrows` method signature:

https://github.com/junit-team/junit5/blob/main/junit-jupiter-api/src/main/java/org/junit/jupiter/api/AssertThrows.java#L41

That is, make this a generic method with a type variable that extends Throwable, and have the return type be this type variable. You'll probably need to adjust the `TestMethod` interface to throw Throwable. And I'd rename the method "assertThrows" as well.

The test library doesn't provide all the same overloads for messages as JUnit does. The prevailing style here is to provide an overload that takes a String message and one that doesn't, so following that seems wise.

test/lib/jdk/test/lib/Asserts.java line 580:

> 578:             fail("No exception was thrown. Expected: " + expected.getName());
> 579:         } catch (Exception exc) {
> 580:             if (expected.isAssignableFrom(exc.getClass())) {

Can use Class.isInstance() here.

test/lib/jdk/test/lib/Asserts.java line 584:

> 582:             } else {
> 583:                 fail("An unexpected exception was thrown. Expected: "
> 584:                         + expected.getName() + " Got: " + exc.getClass().getName());

Use the fail() overload that takes a Throwable.

test/lib/jdk/test/lib/Asserts.java line 588:

> 586:         }
> 587:         // fail() throws a RuntimeException so this is unreachable.
> 588:         return null;

Hm, this is unfortunate. Even though this method throws along all code paths, the compiler doesn't do this analysis. Even though this "never happens" there's still a question of "but what if?" (I guess it could happen if somebody in the future were to modify the code above.) I'd suggest unconditionally throwing an exception here (probably InternalError) to be more explicit. Returning null will result in an inexplicable NPE if somebody dereferences the return value.

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

PR Review: https://git.openjdk.org/jdk/pull/14932#pullrequestreview-1681110752
PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1361372680
PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1361365902
PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1361366051
PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1361366534
PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1361369417

From rriggs at openjdk.org  Tue Oct 17 02:05:25 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Oct 2023 02:05:25 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 23:37:51 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ZoneOffset to parse offset

Looks fine.
(I can't help thinking that some of this pre-processing would be easier to maintain with a bit more formal parsing and creating of records for the data in these files; but that's for another time.)

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1294:

> 1292:             .map(Path::toFile)
> 1293:             .filter(File::isFile)
> 1294:             .forEach(f -> {

I'd keep the Path going through the stream to avoid converting and then back again.
Suggestion:

            .filter(p -> p.toFile().isFile())
            .forEach(p -> {

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1681188045
PR Review Comment: https://git.openjdk.org/jdk/pull/16206#discussion_r1361419853

From liach at openjdk.org  Tue Oct 17 03:12:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Oct 2023 03:12:21 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: 

On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen  wrote:

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed.

src/java.base/share/classes/java/lang/String.java line 932:

> 930: 
> 931:     private static byte[] getBytesNoRepl1(String s, Charset cs) {
> 932:         return getBytesNoRepl1(s, cs);

This method should probably be removed. This current implementation is an infinite recursion.

src/java.base/share/classes/java/util/zip/ZipCoder.java line 319:

> 317:                 }
> 318:             } catch (IllegalArgumentException e) {
> 319:                 return Comparison.NO_MATCH;

Should check if the cause is `CharacterCodingException`

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

Changes requested by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/16209#pullrequestreview-1681283802
PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361455389
PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361455717

From duke at openjdk.org  Tue Oct 17 03:22:56 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 03:22:56 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v2]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: 

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix from @liach 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/aa76c505..d2063b08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=00-01

  Stats: 9 lines in 2 files changed: 4 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209

PR: https://git.openjdk.org/jdk/pull/16209

From joehw at openjdk.org  Tue Oct 17 04:15:25 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 17 Oct 2023 04:15:25 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v2]
In-Reply-To: 
References: 
 
Message-ID: <5r77kjlNZnAkNk9Qrf7efBx9cSbhkdNb6Qj_lT5NGpM=.c52d8342-3674-43e2-b274-408cc93700ea@github.com>

On Mon, 16 Oct 2023 23:37:51 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ZoneOffset to parse offset

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1681329184

From rehn at openjdk.org  Tue Oct 17 06:52:26 2023
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 17 Oct 2023 06:52:26 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v2]
In-Reply-To: 
References: 
 
Message-ID: <3vQCTZow94rNSxugl2YprwwejDZQdeSOjfpV2DerClQ=.3236fb4c-02e1-47f0-82e7-bdb6843dd836@github.com>

On Mon, 16 Oct 2023 21:14:39 GMT, Ilya Gavrilin  wrote:

>> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
>> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
>> 
>> Tests:
>> Performance tests on t-head board:
>> With intrinsics:
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
>> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
>> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
>> 
>> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
>> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
>> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
>> 
>> Regression tests: tier1, hotspot:tier2 on risc-v board.
>> 
>> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
>> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
>> 
>> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> index 6cd1353907e..0bee25366bf 100644
>> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>>  
>>      @Benchmark
>>      public double  copySignDouble() {
>> -        return  Math.copySign(double81, doubleNegative12);
>> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>>      }
>>  
>>      @Benchmark
>>      public float  copySignFloat() {
>> -        return  Math.copySign(floatNegative99, float1);
>> +        return  ...
>
> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some registers usages and typos

Hey, I went ahead and create https://bugs.openjdk.org/browse/JDK-8318216.
So we can track these and not do double work.

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

PR Comment: https://git.openjdk.org/jdk/pull/16186#issuecomment-1765775211

From duke at openjdk.org  Tue Oct 17 07:04:03 2023
From: duke at openjdk.org (yaqsun)
Date: Tue, 17 Oct 2023 07:04:03 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27 [v2]
In-Reply-To: 
References: 
Message-ID: 

> on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
> It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
> But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.

yaqsun has updated the pull request incrementally with two additional commits since the last revision:

 - fixed Whitespace error: del tab
 - 8316563: test tools/jpackage/linux/LinuxResourceTest.java fails on RHEL8 and Fedora 27

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15832/files
  - new: https://git.openjdk.org/jdk/pull/15832/files/a2f982df..06b690b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15832&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15832&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15832/head:pull/15832

PR: https://git.openjdk.org/jdk/pull/15832

From duke at openjdk.org  Tue Oct 17 07:06:19 2023
From: duke at openjdk.org (yaqsun)
Date: Tue, 17 Oct 2023 07:06:19 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 17:24:01 GMT, Alexey Semenyuk  wrote:

> `%define _build_id_links none` must be added to a spec file in LinuxResourceTest.java file. not on `rpmbuild` command line

`%define _build_id_links none` has been added to a spec file in LinuxResourceTest.java file. Please review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15832#issuecomment-1765793256

From pminborg at openjdk.org  Tue Oct 17 08:12:39 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Oct 2023 08:12:39 GMT
Subject: RFR: 8317993: Add capturing factories to classes in java.util.function
 package
Message-ID: 

This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.

The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.

With the new change, it is possible to write code like this (example from `java.util.function.Function`):


// Resolve ambiguity
var function = Function.of(String::isEmpty); // Function
var predicate = Predicate.of(String::isEmpty); // Predicate

// Fluent composition
var chained = Function.of(String::length)       // Function
                   .andThen(Integer::byteValue);      // Function


Please see the original bug report for a comprehensive description of these proposed changes.

Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.

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

Commit messages:
 - Add test and improve
 - Add factories to additional functional interfaces
 - Merge branch 'master' into capturing-factories
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/16213/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16213&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317993
  Stats: 421 lines in 9 files changed: 413 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16213/head:pull/16213

PR: https://git.openjdk.org/jdk/pull/16213

From pminborg at openjdk.org  Tue Oct 17 08:24:24 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Oct 2023 08:24:24 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 08:05:09 GMT, Per Minborg  wrote:

> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
> 
> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
> 
> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
> 
> 
> // Resolve ambiguity
> var function = Function.of(String::isEmpty); // Function
> var predicate = Predicate.of(String::isEmpty); // Predicate
> 
> // Fluent composition
> var chained = Function.of(String::length)       // Function
>                    .andThen(Integer::byteValue);      // Function
> 
> 
> Please see the original bug report for a comprehensive description of these proposed changes.
> 
> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
> 
> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.

src/java.base/share/classes/java/util/function/UnaryOperator.java line 68:

> 66:      * @see Function#andThen(Function)
> 67:      */
> 68:     default UnaryOperator andThenUnary(UnaryOperator after) {

What are your comments on this proposed method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1361715363

From coffeys at openjdk.org  Tue Oct 17 08:50:15 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 17 Oct 2023 08:50:15 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v5]
In-Reply-To: 
References: 
Message-ID: 

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

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 six additional commits since the last revision:

 - update pae exception handling, correct test case typo and improve comments
 - Merge branch 'master' into 8317678-Zip-Source
 - minor test edits and comment updates
 - insert back lastmodified check. enhance testcase. more review comments
 - incorporate review comments
 - Initial changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/519014c7..7f9d3a90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=03-04

  Stats: 9230 lines in 427 files changed: 4465 ins; 2942 del; 1823 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From coffeys at openjdk.org  Tue Oct 17 08:56:28 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 17 Oct 2023 08:56:28 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 08:50:15 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> 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 six additional commits since the last revision:
> 
>  - update pae exception handling, correct test case typo and improve comments
>  - Merge branch 'master' into 8317678-Zip-Source
>  - minor test edits and comment updates
>  - insert back lastmodified check. enhance testcase. more review comments
>  - incorporate review comments
>  - Initial changes

thanks for the reviews and comments to date. I've pushed new changes which should address them. 

Good catch on the ZIPENTRY_NAME typo @jaikiran 
I've run some tests also and it looks like the fileKey() returns the same object/reference - even if symbolic links are used.

you raise an interesting point about `getCanonicalFile()` performance though. I've updated an existing benchmark[1] to check and performance for fileystems that don't support fileKey() (windows) has regressed[2]. Performance is much better on systems that support fileKey() (unix) --  I'll look at it further but perhaps I'll only target the optimizations for the filesystems that support filekey() for now.

[1]

diff --git a/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java b/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
index ffbbc3d245f..34449c14e32 100644
--- a/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
+++ b/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
@@ -29,6 +29,7 @@
 import java.io.FileOutputStream;
 import java.io.IOException;
 import java.nio.file.Files;
+import java.nio.file.Path;
 import java.util.concurrent.TimeUnit;
 import java.util.zip.ZipEntry;
 import java.util.zip.ZipFile;
@@ -50,6 +51,7 @@ public class ZipFileOpen {
     private int size;

     public File zipFile;
+    public File relativePathFile;

     @Setup(Level.Trial)
     public void beforeRun() throws IOException {
@@ -74,6 +76,8 @@ public void beforeRun() throws IOException {
             }
         }
         zipFile = tempFile;
+        relativePathFile = Path.of(System.getProperty("user.dir"))
+                                .relativize(zipFile.toPath()).toFile();
     }

     @Benchmark
@@ -90,4 +94,13 @@ public ZipFile openCloseZipFile() throws Exception {
         zf.close();
         return zf;
     }
+
+    @Benchmark
+    public void openCloseZipFilex2() throws Exception {
+        // Ensure that we only create ZipFile.Source.Key entry per unique zip file
+        ZipFile zf = new ZipFile(zipFile);
+        ZipFile zf2 = new ZipFile(relativePathFile);
+        zf.close();
+        zf2.close();
+    }
 }

[2]

jdk-tip-no-patch:  (Windows)


Benchmark                       (size)  Mode  Cnt       Score        Error  Units
ZipFileOpen.openCloseZipFile       512  avgt   15  319543.232 ?  46112.481  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15  463719.381 ? 139409.316  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15  750838.029 ? 190726.572  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  875174.035 ? 140971.036  ns/op

jdk-with-new-patch
Benchmark                       (size)  Mode  Cnt        Score        Error  Units
ZipFileOpen.openCloseZipFile       512  avgt   15   603053.335 ?  50514.066  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15   710960.542 ?  46343.033  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15  1258566.172 ? 216230.090  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  1260380.961 ? 164216.628  ns/op


[3]


without patch: (Linux)

Benchmark                       (size)  Mode  Cnt       Score       Error  Units
ZipFileOpen.openCloseZipFile       512  avgt   15   75378.890 ?   642.370  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15  150814.293 ? 29801.424  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15  168104.286 ? 41505.778  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  299282.488 ? 44496.777  ns/op
Finished running test 'micro:java.util.zip.ZipFileOpen'


with patch:

Benchmark                       (size)  Mode  Cnt       Score       Error  Units
ZipFileOpen.openCloseZipFile       512  avgt   15   75400.408 ?   408.981  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15  146213.650 ? 15509.167  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15   83194.552 ? 16361.844  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  153956.028 ? 30550.595  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1765969450

From msheppar at openjdk.org  Tue Oct 17 09:00:26 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 17 Oct 2023 09:00:26 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <6evJICW7b-8WiSENDj4nqN7Y_fFRgTO8DWtpkZnxptg=.1dcc2054-b106-4bcf-b930-05deb1fbb6e4@github.com>

On Tue, 17 Oct 2023 00:02:28 GMT, Stuart Marks  wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   retained a reference to the RMI server and improved naming
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 81:
> 
>> 79:                 0, new SslRMIClientSocketFactory(), serverSocketFactory);
>> 80:         HelloClient client = new HelloClient();
>> 81:         client.runClient(stub);
> 
> You could even inline HelloClient here, as I don't think that having a separate class is actually doing anything..

it does emphasize the classic RMI client/server scenario!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1361765127

From fyang at openjdk.org  Tue Oct 17 09:21:28 2023
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 17 Oct 2023 09:21:28 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 21:14:39 GMT, Ilya Gavrilin  wrote:

>> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
>> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
>> 
>> Tests:
>> Performance tests on t-head board:
>> With intrinsics:
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
>> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
>> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
>> 
>> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
>> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
>> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
>> 
>> Regression tests: tier1, hotspot:tier2 on risc-v board.
>> 
>> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
>> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
>> 
>> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> index 6cd1353907e..0bee25366bf 100644
>> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>>  
>>      @Benchmark
>>      public double  copySignDouble() {
>> -        return  Math.copySign(double81, doubleNegative12);
>> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>>      }
>>  
>>      @Benchmark
>>      public float  copySignFloat() {
>> -        return  Math.copySign(floatNegative99, float1);
>> +        return  ...
>
> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some registers usages and typos

Changes requested by fyang (Reviewer).

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1659:

> 1657: // on input we have NaN or +/-0.0 value we should return it,
> 1658: // otherwise return +/- 1.0 using sign of input.
> 1659: // tmp1 - alias for t0 register,

Maybe remove this line (L1659) of the comment?

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1663:

> 1661: // bool is_double - specififes single or double precision operations will be used.
> 1662: void C2_MacroAssembler::signum_fp(FloatRegister dst, FloatRegister src, FloatRegister one, bool is_double) {
> 1663:   assert_different_registers(dst, src, one);

Any reason to keep the assertion?

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1682:

> 1680:   // use floating-point 1.0 with a sign of input
> 1681:   is_double ? fsgnj_d(dst, one, src)
> 1682:             : fsgnj_s(dst, one, src);

What if the `src` argument contains zero? Math.signum(float/double) is supposed to return zero if the argument is zero [1].

[1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2602

src/hotspot/cpu/riscv/riscv.ad line 7537:

> 7535: instruct signumD_reg(fRegD dst, fRegD src, immD zero, fRegD one) %{
> 7536:   match(Set dst (SignumD src (Binary zero one)));
> 7537:   effect(TEMP_DEF dst, USE src, USE one);

Any reason to keep this effect?

src/hotspot/cpu/riscv/riscv.ad line 7548:

> 7546: instruct signumF_reg(fRegF dst, fRegF src, immF zero, fRegF one) %{
> 7547:   match(Set dst (SignumF src (Binary zero one)));
> 7548:   effect(TEMP_DEF dst, USE src, USE one);

Any reason to keep this effect?

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

PR Review: https://git.openjdk.org/jdk/pull/16186#pullrequestreview-1681791129
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1361790804
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1361788992
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1361782859
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1361793207
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1361793356

From redestad at openjdk.org  Tue Oct 17 09:34:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Oct 2023 09:34:22 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v2]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 03:09:09 GMT, Chen Liang  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix from @liach 's review
>
> The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed.

I agree with @liach that `Files.readString / writeString` should continue to throw `CCE`, not `IAE`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766035016

From igavrilin at openjdk.org  Tue Oct 17 09:58:19 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Tue, 17 Oct 2023 09:58:19 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 17 Oct 2023 09:09:52 GMT, Fei Yang  wrote:

>> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some registers usages and typos
>
> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1682:
> 
>> 1680:   // use floating-point 1.0 with a sign of input
>> 1681:   is_double ? fsgnj_d(dst, one, src)
>> 1682:             : fsgnj_s(dst, one, src);
> 
> What if the `src` argument contains zero? Math.signum(float/double) is supposed to return zero if the argument is zero [1].
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2602

According to IEEE754, we can get positive or negative zero in the `src` register (also positive zero can be named as zero) , and these cases included to mask for the tmp1 (L1671-1676) and `src` value returned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1361840030

From alanb at openjdk.org  Tue Oct 17 10:36:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 10:36:14 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v2]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 03:09:09 GMT, Chen Liang  wrote:

> The thrown CCE was intended for `Files.readString` and `Files.writeString`, and is in reality, only used by those 2 sites. However, you missed updating those sites, so they now throw IAE instead of CCE, which should be fixed.

Right, these APIs are specified to throw an IOException "If an I/O error occurs reading from the file or a malformed or unmappable byte sequence is read". Changing this to throw an unexpected IAE would be a breaking change. So good to spot this. Need to make sure that tier2 tests are run with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766104613

From duke at openjdk.org  Tue Oct 17 10:42:59 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 10:42:59 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v3]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com>

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Files.readString/writeString throws CCE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/d2063b08..a93be313

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=01-02

  Stats: 22 lines in 3 files changed: 16 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209

PR: https://git.openjdk.org/jdk/pull/16209

From redestad at openjdk.org  Tue Oct 17 10:45:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Oct 2023 10:45:22 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v3]
In-Reply-To: <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 <0eqpx3flw8fApB9XC6n5Qnvelx2A7EVDR9QXcXa4GEE=.ac6f2d97-6d4f-4b72-8a9f-f9eb4883ae8c@github.com>
Message-ID: 

On Tue, 17 Oct 2023 10:42:59 GMT, Shaojin Wen  wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files.readString/writeString throws CCE

test/jdk/java/lang/String/NoReplTest.java line 62:

> 60:                             .withUpperCase()
> 61:                             .formatHex(read.getBytes(UTF_16)));
> 62:         } catch (CharacterCodingException cce) {

Shouldn't these test changes be completely reverted now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361904067

From duke at openjdk.org  Tue Oct 17 11:11:52 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 11:11:52 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: 

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  revert NoReplTest, from @cl4es 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/a93be313..cc3bc9ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=02-03

  Stats: 13 lines in 1 file changed: 0 ins; 9 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209

PR: https://git.openjdk.org/jdk/pull/16209

From mcimadamore at openjdk.org  Tue Oct 17 11:12:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 17 Oct 2023 11:12:09 GMT
Subject: Integrated: 8318180: Memory model reference from foreign package-info
 is broken
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 16:19:41 GMT, Maurizio Cimadamore  wrote:

> This PR fixes a wrong reference to the JLS memory model section.

This pull request has now been integrated.

Changeset: b2b8db65
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/b2b8db65337729c73a988942c4d1d287d90ff769
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8318180: Memory model reference from foreign package-info is broken

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jdk/pull/16204

From alanb at openjdk.org  Tue Oct 17 11:15:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 11:15:51 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen  wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert NoReplTest, from @cl4es 's review

src/java.base/share/classes/java/nio/file/Files.java line 3361:

> 3359:                 throw cause;
> 3360:             }
> 3361:             throw e;

This is wrong, if IAE is thrown for any other reason than CharacterCodingException then it means the JDK is broken.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16209#discussion_r1361937982

From alanb at openjdk.org  Tue Oct 17 11:19:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 11:19:00 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen  wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert NoReplTest, from @cl4es 's review

I've set this PR to require two Reviewers as there is obvious breakage here and no evidence that the tier2 tests have been run.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766203522

From mdonovan at openjdk.org  Tue Oct 17 11:35:20 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 17 Oct 2023 11:35:20 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 16 Oct 2023 23:56:24 GMT, Stuart Marks  wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   retained a reference to the RMI server and improved naming
>
> test/lib/jdk/test/lib/Asserts.java line 588:
> 
>> 586:         }
>> 587:         // fail() throws a RuntimeException so this is unreachable.
>> 588:         return null;
> 
> Hm, this is unfortunate. Even though this method throws along all code paths, the compiler doesn't do this analysis. Even though this "never happens" there's still a question of "but what if?" (I guess it could happen if somebody in the future were to modify the code above.) I'd suggest unconditionally throwing an exception here (probably InternalError) to be more explicit. Returning null will result in an inexplicable NPE if somebody dereferences the return value.

Actually, this is a mistake. If I call `fail()` immediately after the test method executes (because an exception wasn't thrown), the RuntimeException which will promptly be caught in my try/catch and that isn't what we want. I'm moving that invocation to the end which looks and works a lot better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1361958521

From mcimadamore at openjdk.org  Tue Oct 17 11:45:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 17 Oct 2023 11:45:48 GMT
Subject: RFR: 8318295: Update launcher help for enable-native-access
Message-ID: <6a9cj7OZ9wI4lbBBFNmUYkO8O4vlO9oUl61QZuZfEtU=.77436b95-f41b-4569-a282-4036b5494ca5@github.com>

This simple PR updates the description of the `enable-native-access` option in the launcher properties file.

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

Commit messages:
 - Initial push

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

PR: https://git.openjdk.org/jdk/pull/16217

From duke at openjdk.org  Tue Oct 17 12:02:14 2023
From: duke at openjdk.org (Agnibho Hom Chowdhury)
Date: Tue, 17 Oct 2023 12:02:14 GMT
Subject: Integrated: JDK-8249832:
 java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id
In-Reply-To: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
References: <-O2dbEXK0UHj4_mJTvmcTbIb3BqHc2LIYH9rfmTLCmY=.503c3130-0365-4da4-af8b-e714d7d48bab@github.com>
Message-ID: 

On Fri, 6 Oct 2023 12:43:02 GMT, Agnibho Hom Chowdhury  wrote:

> Please review this PR as a fix of [JDK-8249832](https://bugs.openjdk.org/browse/JDK-8249832). I have added the bug with after @ignore annotation.

This pull request has now been integrated.

Changeset: 34653c1e
Author:    Agnibho Hom Chowdhury 
Committer: Mahendra Chhipa 
URL:       https://git.openjdk.org/jdk/commit/34653c1e73452c0e07beb1f5e2eb8029fdb3befc
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8249832: java/util/zip/DataDescriptorSignatureMissing.java uses @ignore w/o bug-id

Reviewed-by: msheppar

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

PR: https://git.openjdk.org/jdk/pull/16073

From duke at openjdk.org  Tue Oct 17 12:22:33 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 17 Oct 2023 12:22:33 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 08:05:09 GMT, Per Minborg  wrote:

> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
> 
> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
> 
> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
> 
> 
> // Resolve ambiguity
> var function = Function.of(String::isEmpty); // Function
> var predicate = Predicate.of(String::isEmpty); // Predicate
> 
> // Fluent composition
> var chained = Function.of(String::length)       // Function
>                    .andThen(Integer::byteValue);      // Function
> 
> 
> Please see the original bug report for a comprehensive description of these proposed changes.
> 
> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
> 
> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.

The?factory?methods should?probably use?bounded?wildcards.

src/java.base/share/classes/java/util/function/BiConsumer.java line 104:

> 102:      * @param  the type of the second argument to the operation
> 103:      */
> 104:     static  BiConsumer of(BiConsumer uncaptured) {

Suggestion:

    static  BiConsumer of(BiConsumer uncaptured) {

src/java.base/share/classes/java/util/function/BiFunction.java line 94:

> 92:      * @param  the type of the result of the function
> 93:      */
> 94:     static  BiFunction of(BiFunction uncaptured) {

Suggestion:

    static  BiFunction of(BiFunction uncaptured) {

src/java.base/share/classes/java/util/function/BiPredicate.java line 128:

> 126:      * @param  the type of the second argument the predicate
> 127:      */
> 128:     static  BiPredicate of(BiPredicate uncaptured) {

Suggestion:

    static  BiPredicate of(BiPredicate uncaptured) {

src/java.base/share/classes/java/util/function/Consumer.java line 87:

> 85:      * @param  the type of the input to the operation
> 86:      */
> 87:     static  Consumer of(Consumer uncaptured) {

Suggestion:

    static  Consumer of(Consumer uncaptured) {

src/java.base/share/classes/java/util/function/Function.java line 121:

> 119:      * @param  the type of the result of the function
> 120:      */
> 121:     static  Function of(Function uncaptured) {

Suggestion:

    static  Function of(Function uncaptured) {

src/java.base/share/classes/java/util/function/Predicate.java line 160:

> 158:      * @param  the type of the input to the predicate
> 159:      */
> 160:     static  Predicate of(Predicate uncaptured) {

Suggestion:

    static  Predicate of(Predicate uncaptured) {

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

PR Review: https://git.openjdk.org/jdk/pull/16213#pullrequestreview-1682167914
PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362019934
PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362020142
PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362020330
PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362020494
PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362020680
PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362020826

From lkorinth at openjdk.org  Tue Oct 17 12:29:46 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 17 Oct 2023 12:29:46 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v4]
In-Reply-To: 
References: 
Message-ID: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * 
 Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      *  and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:

 - Revert "8315097: Rename createJavaProcessBuilder"
   
   This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
 - Revert "copyright"
   
   This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
 - Revert "fix static import"
   
   This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/27da7150..44af07b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=02-03

  Stats: 1102 lines in 462 files changed: 11 ins; 22 del; 1069 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

PR: https://git.openjdk.org/jdk/pull/15452

From rgiulietti at openjdk.org  Tue Oct 17 12:39:13 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Oct 2023 12:39:13 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v21]
In-Reply-To: <8yU_xOd6jajN9pJ2Hjvs-ye4BV2hbnMlyVmxP_CqL-0=.08fab3e6-4cd1-4f72-801e-2c2d2210ce9e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <8yU_xOd6jajN9pJ2Hjvs-ye4BV2hbnMlyVmxP_CqL-0=.08fab3e6-4cd1-4f72-801e-2c2d2210ce9e@github.com>
Message-ID: 

On Mon, 16 Oct 2023 19:16:41 GMT, Aggelos Biboudis  wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust javadoc on ExactConversionsSupport

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 40:

> 38:  *
> 39:  * @implNote Methods that describe a conversion check among unconditionally exact types
> 40:  * (they would return true) are ommited. Similarly, methods that describe a conversion check

Suggestion:

 * (they would return true) are omitted. Similarly, methods that describe a conversion check

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 54:

> 52:      * Exactness method from int to byte
> 53:      * @param n value
> 54:      * @return  true if the passed value can be converted exactly to the target type

Suggestion:

     * @return  true if and only if the passed value can be converted exactly to the target type

Without the "only if", the method could simply always return `true` while meeting the `@return` "contract" ;-)

Alternatively
Suggestion:

     * @return  whether or not the passed value can be converted exactly to the target type


Similarly for all other methods.

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 80:

> 78:      * specification of the {@linkplain Double} class.
> 79:      */
> 80:     public static boolean isIntToFloatExact(int n) { return n == (int)(float)n && n != Integer.MAX_VALUE; }

Suggestion:

    public static boolean isIntToFloatExact(int n) {
        return n == (int)(float)n && n != Integer.MAX_VALUE;
    }

Nit: what about formatting this on 3 lines?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362005727
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362008344
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362043660

From pminborg at openjdk.org  Tue Oct 17 12:41:41 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Oct 2023 12:41:41 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 08:05:09 GMT, Per Minborg  wrote:

> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
> 
> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
> 
> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
> 
> 
> // Resolve ambiguity
> var function = Function.of(String::isEmpty); // Function
> var predicate = Predicate.of(String::isEmpty); // Predicate
> 
> // Fluent composition
> var chained = Function.of(String::length)       // Function
>                    .andThen(Integer::byteValue);      // Function
> 
> 
> Please see the original bug report for a comprehensive description of these proposed changes.
> 
> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
> 
> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.

Maybe we should add a section to the java docs where we explain the implication if using a method reference and an overload is added later?

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

PR Comment: https://git.openjdk.org/jdk/pull/16213#issuecomment-1766335165

From rgiulietti at openjdk.org  Tue Oct 17 13:04:18 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Oct 2023 13:04:18 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 12:16:54 GMT, ExE Boss  wrote:

>> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
>> 
>> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
>> 
>> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
>> 
>> 
>> // Resolve ambiguity
>> var function = Function.of(String::isEmpty); // Function
>> var predicate = Predicate.of(String::isEmpty); // Predicate
>> 
>> // Fluent composition
>> var chained = Function.of(String::length)       // Function
>>                    .andThen(Integer::byteValue);      // Function
>> 
>> 
>> Please see the original bug report for a comprehensive description of these proposed changes.
>> 
>> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
>> 
>> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.
>
> src/java.base/share/classes/java/util/function/BiConsumer.java line 104:
> 
>> 102:      * @param  the type of the second argument to the operation
>> 103:      */
>> 104:     static  BiConsumer of(BiConsumer uncaptured) {
> 
> Suggestion:
> 
>     static  BiConsumer of(BiConsumer uncaptured) {

@ExE-Boss This and all other "enhancements" hardly compile ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362076569

From asemenyuk at openjdk.org  Tue Oct 17 14:02:28 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 17 Oct 2023 14:02:28 GMT
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 22:15:00 GMT, Alexander Matveev  wrote:

> - Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
> - If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
>> Error: "codesign" failed with following output:
>> test: no identity found
> 
>> Error: "productbuild" failed with following output:
>> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
> - Added error handling not to allow invalid combinations of signing options.
> - Updated signing tests to test new changes.

If I get it right from the code, if `--mac-app-image-sign-identity` or `--mac-installer-sign-identity` option is specified and `--mac-sign` is NOT, it is an error. What is the point in `--mac-sign` then? It looks redundant.

If we still want `--mac-sign` to have any meaning when `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` are used let's make jpackage silently ignore any signing options if `--mac-sign` is not specified.

E.g.:
`jpackage --mac-app-image-sign-identity foo` - no error and no signing

`jpackage --mac-app-image-sign-identity foo --mac-sign` - no error, run signing

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

PR Comment: https://git.openjdk.org/jdk/pull/16085#issuecomment-1766410728

From rgiulietti at openjdk.org  Tue Oct 17 14:03:02 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Oct 2023 14:03:02 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 08:05:09 GMT, Per Minborg  wrote:

> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
> 
> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
> 
> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
> 
> 
> // Resolve ambiguity
> var function = Function.of(String::isEmpty); // Function
> var predicate = Predicate.of(String::isEmpty); // Predicate
> 
> // Fluent composition
> var chained = Function.of(String::length)       // Function
>                    .andThen(Integer::byteValue);      // Function
> 
> 
> Please see the original bug report for a comprehensive description of these proposed changes.
> 
> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
> 
> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.

src/java.base/share/classes/java/util/function/BiConsumer.java line 78:

> 76:     /**
> 77:      * {@return a representation of the provided {@code uncaptured} lambda or method reference
> 78:      * in the form of a {@code BiConsumer}}

There's no need for the provided arguments to this and the other "of" methods to be a lambda or a method reference expression, although it is true all that the methods are useful especially for such cases.

src/java.base/share/classes/java/util/function/BiConsumer.java line 105:

> 103:      */
> 104:     static  BiConsumer of(BiConsumer uncaptured) {
> 105:         return Objects.requireNonNull(uncaptured);

This does more than just capturing: not sure if the `null` check is generally useful here and elsewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362091242
PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362105477

From jvernee at openjdk.org  Tue Oct 17 14:02:47 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 17 Oct 2023 14:02:47 GMT
Subject: RFR: 8318295: Update launcher help for enable-native-access
In-Reply-To: <6a9cj7OZ9wI4lbBBFNmUYkO8O4vlO9oUl61QZuZfEtU=.77436b95-f41b-4569-a282-4036b5494ca5@github.com>
References: <6a9cj7OZ9wI4lbBBFNmUYkO8O4vlO9oUl61QZuZfEtU=.77436b95-f41b-4569-a282-4036b5494ca5@github.com>
Message-ID: 

On Tue, 17 Oct 2023 11:38:17 GMT, Maurizio Cimadamore  wrote:

> This simple PR updates the description of the `enable-native-access` option in the launcher properties file.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16217#pullrequestreview-1682369664

From asemenyuk at openjdk.org  Tue Oct 17 14:03:11 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 17 Oct 2023 14:03:11 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 07:04:03 GMT, yaqsun  wrote:

>> on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
>> It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
>> But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.
>
> yaqsun has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed Whitespace error: del tab
>  - 8316563: test tools/jpackage/linux/LinuxResourceTest.java fails on RHEL8 and Fedora 27

Marked as reviewed by asemenyuk (Reviewer).

Thank you for updating the patch!

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

PR Review: https://git.openjdk.org/jdk/pull/15832#pullrequestreview-1682363774
PR Comment: https://git.openjdk.org/jdk/pull/15832#issuecomment-1766417232

From rgiulietti at openjdk.org  Tue Oct 17 14:03:02 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Oct 2023 14:03:02 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 13:12:08 GMT, Raffaello Giulietti  wrote:

>> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
>> 
>> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
>> 
>> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
>> 
>> 
>> // Resolve ambiguity
>> var function = Function.of(String::isEmpty); // Function
>> var predicate = Predicate.of(String::isEmpty); // Predicate
>> 
>> // Fluent composition
>> var chained = Function.of(String::length)       // Function
>>                    .andThen(Integer::byteValue);      // Function
>> 
>> 
>> Please see the original bug report for a comprehensive description of these proposed changes.
>> 
>> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
>> 
>> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.
>
> src/java.base/share/classes/java/util/function/BiConsumer.java line 78:
> 
>> 76:     /**
>> 77:      * {@return a representation of the provided {@code uncaptured} lambda or method reference
>> 78:      * in the form of a {@code BiConsumer}}
> 
> There's no need for the provided arguments to this and the other "of" methods to be a lambda or a method reference expression, although it is true all that the methods are useful especially for such cases.

Also, is "capturing" the right term? IIRC, the JLS speaks about capture conversions for wildcards, but I'm not sure that the JLS concept also applies here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1362113285

From rgiulietti at openjdk.org  Tue Oct 17 14:12:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Oct 2023 14:12:07 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 11:11:52 GMT, Shaojin Wen  wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert NoReplTest, from @cl4es 's review

@wenshao The proposal changes the exception types for seemingly no reason.
What concrete problem does this enhancement PR address?

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766499191

From mdoerr at openjdk.org  Tue Oct 17 14:17:20 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 17 Oct 2023 14:17:20 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v5]
In-Reply-To: 
References: 
Message-ID: 

> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI.

Martin Doerr has updated the pull request incrementally with two additional commits since the last revision:

 - Improve handling of layouts in NativeType.java
 - Check byte order of 4-byte aligned double.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16179/files
  - new: https://git.openjdk.org/jdk/pull/16179/files/17b300ce..3caaf93b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16179&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16179&range=03-04

  Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16179/head:pull/16179

PR: https://git.openjdk.org/jdk/pull/16179

From jvernee at openjdk.org  Tue Oct 17 14:17:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 17 Oct 2023 14:17:21 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v5]
In-Reply-To: 
References: 
 
Message-ID: <15NdCw0i8H9MC2yQDWzWaSq8S2E1YHYkM6EeC14nUzY=.480ba8f7-76f7-421a-aec4-36fbbafd9082@github.com>

On Tue, 17 Oct 2023 14:12:27 GMT, Martin Doerr  wrote:

>> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI.
>
> Martin Doerr has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve handling of layouts in NativeType.java
>  - Check byte order of 4-byte aligned double.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16179#pullrequestreview-1682485962

From mdoerr at openjdk.org  Tue Oct 17 14:17:25 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 17 Oct 2023 14:17:25 GMT
Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function &
 Memory API [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 16 Oct 2023 22:56:42 GMT, Jorn Vernee  wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to PlatformLayouts.java
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java line 64:
> 
>> 62:         // Note: It is possible to enforce 8-byte alignment by #pragma align (natural)
>> 63:         // Therefore, we use normal checks if we are already 8-byte aligned.
>> 64:         if ((offset % 8 != 0) && (member instanceof ValueLayout vl && vl.carrier() == double.class)) {
> 
> I think you should check for the correct byte order as well at some point, for this special case

Done. Thanks!

> test/micro/org/openjdk/bench/java/lang/foreign/pointers/NativeType.java line 61:
> 
>> 59:         @Override
>> 60:         public ValueLayout.OfInt layout() {
>> 61:             return (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int");
> 
> For this benchmark, we rely on constant folding through these layouts. So, we shouldn't go through `canonicalLayouts` here. We can store the layout in a `static final` field, and then return it here instead.

Done. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1362195270
PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1362194981

From duke at openjdk.org  Tue Oct 17 14:22:10 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 14:22:10 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: 

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix from @AlanBateman 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16209/files
  - new: https://git.openjdk.org/jdk/pull/16209/files/cc3bc9ed..f7023991

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16209&range=03-04

  Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16209/head:pull/16209

PR: https://git.openjdk.org/jdk/pull/16209

From duke at openjdk.org  Tue Oct 17 14:36:40 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 14:36:40 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
 
Message-ID: 

On Tue, 17 Oct 2023 14:09:08 GMT, Raffaello Giulietti  wrote:

> @wenshao The proposal changes the exception types for seemingly no reason. What concrete problem does this enhancement PR address?

@lianch 's suggestion in PR #14812 : 
"Make the NoRepl methods throw IllegalArgument (like NoRepl1 do) by default; move the exception handling logic into Files implementation, the only place where it's actually needed. "

We used noRepl in UUID/HexFormat to handle CCE. I felt that the code was not clean enough, so I submitted this PR.

After the discussion above, I found that things are not that simple. Should I continue this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766540065

From liach at openjdk.org  Tue Oct 17 14:43:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Oct 2023 14:43:52 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v4]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
 
 
Message-ID: 

On Tue, 17 Oct 2023 14:30:26 GMT, Shaojin Wen  wrote:

> @wenshao The proposal changes the exception types for seemingly no reason.
> What concrete problem does this enhancement PR address?

@rgiulietti The API was exposed to create a String without duplicating an array in compatible encoding. Initially they are added for Files.readString and writeString, which has a custom exception logic. However, in the coming years, the usages for no-replication has grown, but no other user needs the CCE behavior, which makes code complex. As a result, we are proposing to localize the CCE logoc to Files.readString and writeString so other use sites can call the APIs without try-catch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1766561936

From abimpoudis at openjdk.org  Tue Oct 17 14:44:38 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 14:44:38 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v22]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Improve javadoc of ExactConversionsSupport
  
  Co-authored-by: Raffaello Giulietti 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ac0b6782..b9237148

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=20-21

  Stats: 25 lines in 1 file changed: 1 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Tue Oct 17 14:44:48 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 14:44:48 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v21]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <8yU_xOd6jajN9pJ2Hjvs-ye4BV2hbnMlyVmxP_CqL-0=.08fab3e6-4cd1-4f72-801e-2c2d2210ce9e@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 12:06:53 GMT, Raffaello Giulietti  wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust javadoc on ExactConversionsSupport
>
> src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 54:
> 
>> 52:      * Exactness method from int to byte
>> 53:      * @param n value
>> 54:      * @return  true if the passed value can be converted exactly to the target type
> 
> Suggestion:
> 
>      * @return  true if and only if the passed value can be converted exactly to the target type
> 
> Without the "only if", the method could simply always return `true` while meeting the `@return` "contract" ;-)
> 
> Alternatively
> Suggestion:
> 
>      * @return  whether or not the passed value can be converted exactly to the target type
> 
> 
> Similarly for all other methods.

Good point! Thx

> src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 80:
> 
>> 78:      * specification of the {@linkplain Double} class.
>> 79:      */
>> 80:     public static boolean isIntToFloatExact(int n) { return n == (int)(float)n && n != Integer.MAX_VALUE; }
> 
> Suggestion:
> 
>     public static boolean isIntToFloatExact(int n) {
>         return n == (int)(float)n && n != Integer.MAX_VALUE;
>     }
> 
> Nit: what about formatting this on 3 lines?

Looks better indeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362247167
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362247460

From duke at openjdk.org  Tue Oct 17 14:55:16 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 14:55:16 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: <3sPNjUiD-FXja-kgO00QKRlOUDENjQwUlUZEdaNsVPs=.37216e59-cfd5-4c7f-98a5-acfabcea371b@github.com>

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

> Good, narrows it down to what's going on in `prepend(long, byte[], String)`. Might boil down to `System.arraycopy`. This method might not be optimized for tiny arrays on all platforms. Specializing for single-char case:
> 
> ```java
> diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
> index 9b19d7e2ac1..6eb70925dab 100644
> --- a/src/java.base/share/classes/java/lang/String.java
> +++ b/src/java.base/share/classes/java/lang/String.java
> @@ -4723,7 +4723,11 @@ static void repeatCopyRest(byte[] buffer, int offset, int limit, int copied) {
>       */
>      void getBytes(byte[] dst, int dstBegin, byte coder) {
>          if (coder() == coder) {
> -            System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
> +            if (value.length == 1) {
> +                dst[(dstBegin << coder)] = value[0];
> +            } else {
> +                System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
> +            }
>          } else {    // this.coder == LATIN && coder == UTF16
>              StringLatin1.inflate(value, 0, dst, dstBegin, value.length);
>          }
> ```
> 
> .. seem to help the JIT do the right thing consistently, too:
> 
> ```
> Benchmark                                 Mode  Cnt   Score   Error  Units
> BigDecimals.testSmallToEngineeringString  avgt   50  11,757 ? 0,480  ns/op
> ```

This is faster, but can I make this change to String.getBytes in this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1766584318

From redestad at openjdk.org  Tue Oct 17 15:02:10 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 17 Oct 2023 15:02:10 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

I think it would be better to consider this change to `String.getBytes` separately and evaluate it on more platforms and on more benchmarks. I don't think action on that should block this PR. In fact if you go with the simpler recipe (`"\1.\1\1"`) the `BigDecimals.testSmallToEng` becomes a good test case to verify such an optimization in a later RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1766598900

From duke at openjdk.org  Tue Oct 17 15:34:52 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 17 Oct 2023 15:34:52 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

After using recipe ("\1.\1\1") and modifying String.getBytes, there will still be occasional slowdowns. I haven't found the reason yet.


# Run progress: 0.00% complete, ETA 00:00:30
# Fork: 1 of 3
# Warmup Iteration   1: 23.557 ns/op
# Warmup Iteration   2: 20.149 ns/op
# Warmup Iteration   3: 21.658 ns/op
# Warmup Iteration   4: 21.239 ns/op
# Warmup Iteration   5: 20.374 ns/op
Iteration   1: 20.120 ns/op
Iteration   2: 19.952 ns/op
Iteration   3: 20.381 ns/op
Iteration   4: 20.531 ns/op
Iteration   5: 20.468 ns/op

# Run progress: 33.33% complete, ETA 00:00:23
# Fork: 2 of 3
# Warmup Iteration   1: 13.481 ns/op
# Warmup Iteration   2: 11.702 ns/op
# Warmup Iteration   3: 11.963 ns/op
# Warmup Iteration   4: 11.982 ns/op
# Warmup Iteration   5: 11.965 ns/op
Iteration   1: 11.946 ns/op
Iteration   2: 11.961 ns/op
Iteration   3: 11.988 ns/op
Iteration   4: 11.980 ns/op
Iteration   5: 11.969 ns/op

# Run progress: 66.67% complete, ETA 00:00:10
# Fork: 3 of 3
# Warmup Iteration   1: 13.148 ns/op
# Warmup Iteration   2: 11.542 ns/op
# Warmup Iteration   3: 11.991 ns/op
# Warmup Iteration   4: 12.015 ns/op
# Warmup Iteration   5: 12.012 ns/op
Iteration   1: 11.977 ns/op
Iteration   2: 11.988 ns/op
Iteration   3: 12.006 ns/op
Iteration   4: 11.988 ns/op
Iteration   5: 11.986 ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1766665040

From liach at openjdk.org  Tue Oct 17 15:59:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Oct 2023 15:59:20 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: <0GO4Vo0XtxBy3CpeFxIX3Jo9siV-PrYOZhGJ0gU-MmI=.eceeb6c4-1581-40df-8a17-9f8fb9c70be9@github.com>

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

Can you export jfr recordings of two different runs to check?

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1766711581

From jlaskey at openjdk.org  Tue Oct 17 16:03:25 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 17 Oct 2023 16:03:25 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v3]
In-Reply-To: 
References: 
Message-ID: <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com>

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Cache process method type in JCStringTemplate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/f077ef6f..ae136779

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=01-02

  Stats: 13 lines in 3 files changed: 2 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

PR: https://git.openjdk.org/jdk/pull/16202

From jlaskey at openjdk.org  Tue Oct 17 16:03:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 17 Oct 2023 16:03:28 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 16 Oct 2023 16:51:14 GMT, Jim Laskey  wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1691:
>> 
>>> 1689:         }
>>> 1690: 
>>> 1691:         private Type getProcessMethodType(JCStringTemplate tree, Type processorType) {
>> 
>> This method is basically the same as in `Attr`, correct? I wonder if there's a way to avoid the duplication? One possibility would be to compute the type in `Attr`, and store it in a field on `JCStringTemplate`, and just use it in `Flow`. Alternatively, it could be shared in some class, although only `TreeInfo` and `Resolve` come to mind, and neither seem particularly suitable for that.
>
> I thought of the TreeInfo and Resolve idea but the number of arguments required made it messy. Hanging off of JCStringTemplate seemed like clutter to me. If I could use the method symbol in TransLiterals it might make sense. I'll ponder on it.

Added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1362377976

From mcimadamore at openjdk.org  Tue Oct 17 16:41:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 17 Oct 2023 16:41:11 GMT
Subject: Integrated: 8318295: Update launcher help for enable-native-access
In-Reply-To: <6a9cj7OZ9wI4lbBBFNmUYkO8O4vlO9oUl61QZuZfEtU=.77436b95-f41b-4569-a282-4036b5494ca5@github.com>
References: <6a9cj7OZ9wI4lbBBFNmUYkO8O4vlO9oUl61QZuZfEtU=.77436b95-f41b-4569-a282-4036b5494ca5@github.com>
Message-ID: 

On Tue, 17 Oct 2023 11:38:17 GMT, Maurizio Cimadamore  wrote:

> This simple PR updates the description of the `enable-native-access` option in the launcher properties file.

This pull request has now been integrated.

Changeset: 39e2b7a6
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/39e2b7a6d39d7552e44ccc7e9ee2bfa426698141
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8318295: Update launcher help for enable-native-access

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jdk/pull/16217

From naoto at openjdk.org  Tue Oct 17 16:52:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Oct 2023 16:52:12 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
Message-ID: 

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Delay populating GMT format at runtime. Reflecting review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16206/files
  - new: https://git.openjdk.org/jdk/pull/16206/files/3d221558..4559203d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16206&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16206&range=01-02

  Stats: 10 lines in 1 file changed: 4 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16206.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16206/head:pull/16206

PR: https://git.openjdk.org/jdk/pull/16206

From naoto at openjdk.org  Tue Oct 17 16:53:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Oct 2023 16:53:41 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <9aZ-oyXU5G9Ya7mq0J9X_oPER9a25nm_SuJd-qrNFBE=.fadeb8f7-9da2-4931-9504-3f86862004bc@github.com>

On Tue, 17 Oct 2023 02:03:06 GMT, Roger Riggs  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use ZoneOffset to parse offset
>
> Looks fine.
> (I can't help thinking that some of this pre-processing would be easier to maintain with a bit more formal parsing and creating of records for the data in these files; but that's for another time.)

Thanks for the reviews, @RogerRiggs @JoeWang-Java . I now realized that the pre-filling of GMT format in the CLDR resource would prevent COMPAT from populating its short names (as it does today), so I changed the fix not to pre-fill GMT short names. Once COMPAT is gone in the future, this workaround needs to be revisited.

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

PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1766806066

From rgiulietti at openjdk.org  Tue Oct 17 17:07:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Oct 2023 17:07:17 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: <_6YiEO1xFMUqaKroqhxKPNOYTlVLzeCtaX36C0r1vEQ=.84aac4d8-f464-4cd3-b62e-27f83f0ff8ed@github.com>

On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen  wrote:

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

src/java.base/share/classes/java/util/FormatProcessor.java line 234:

> 232:             }
> 233: 
> 234:             char c = fragment.charAt(i);

I think that `c` can be checked against `%` or `n` right here.
A consequence is that the parser will never be `reset()` and there's no need for the `if` below.

src/java.base/share/classes/java/util/FormatProcessor.java line 257:

> 255:                 group = fragment.substring(i - 1, i + off + 1);
> 256:             } else {
> 257:                 group = String.valueOf(c);

The original code throws when (1) there is a match _and_ (2) it is not at the end of the fragment or it is not needed.

AFAIU, here, `off` can only be `0`, which means that the parser didn't find a match.
Throwing an exception is different behavior than the original code.

Let me know if I'm wrong with my understanding of the proposed code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1362465703
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1362469833

From vromero at openjdk.org  Tue Oct 17 17:51:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 17:51:08 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v22]
In-Reply-To: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 14:44:38 GMT, Aggelos Biboudis  wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadoc of ExactConversionsSupport
>   
>   Co-authored-by: Raffaello Giulietti 

thanks! lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15638#pullrequestreview-1683007779

From rriggs at openjdk.org  Tue Oct 17 18:09:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Oct 2023 18:09:59 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
Message-ID: <2s6POSrQenTCvzxYraKH7J4oGJ4UqTiDl5ppDTYZ1fM=.fdb440b4-d33e-46e2-98b5-bd629b2b8c3e@github.com>

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen  wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

Hacking around the exception types isn't a good fix.
If the exception is thrown, it is because of a charset conversion error.
IllegalArgumentException is for cases where the arguments are incorrect.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16209#pullrequestreview-1683043411

From joehw at openjdk.org  Tue Oct 17 19:50:45 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 17 Oct 2023 19:50:45 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
 
Message-ID: <2kt6xqbf9RkKp2vEmzoBJHntKtH66Gd5-F4U6mmzhFo=.580d4b70-e302-4958-b1ca-4a8d79ceeba6@github.com>

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Marked as reviewed by joehw (Reviewer).

Thanks Naoto for the update. Sounds like a good plan to me.

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683235181
PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1767061468

From coffeys at openjdk.org  Tue Oct 17 19:55:19 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 17 Oct 2023 19:55:19 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v6]
In-Reply-To: 
References: 
Message-ID: <35TteAwG-KgyaZ-o2hdjrz7YinTZMTPPII-WFbg3Los=.266223d5-e336-45c2-8d8d-da626f61de50@github.com>

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  remove getCanonicalFile calls, update ZipFile jmh benchmark test, tidy up junit test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/7f9d3a90..cfa65c05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=04-05

  Stats: 61 lines in 3 files changed: 28 ins; 25 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From lancea at openjdk.org  Tue Oct 17 19:57:47 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 17 Oct 2023 19:57:47 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683251272

From coffeys at openjdk.org  Tue Oct 17 19:58:49 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 17 Oct 2023 19:58:49 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v6]
In-Reply-To: <35TteAwG-KgyaZ-o2hdjrz7YinTZMTPPII-WFbg3Los=.266223d5-e336-45c2-8d8d-da626f61de50@github.com>
References: 
 <35TteAwG-KgyaZ-o2hdjrz7YinTZMTPPII-WFbg3Los=.266223d5-e336-45c2-8d8d-da626f61de50@github.com>
Message-ID: 

On Tue, 17 Oct 2023 19:55:19 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove getCanonicalFile calls, update ZipFile jmh benchmark test, tidy up junit test

Removed the `getCanonicalFile `calls. The patch now optimizes the case where fileKey() is supported. Updated the ZipFileOpen.java benchmark test case also. before and after benchmark results for linux and windows posted below


linux:
without patch:

Benchmark                       (size)  Mode  Cnt       Score       Error  Units
ZipFileOpen.openCloseZipFile       512  avgt   15   75378.890 ?   642.370  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15  150814.293 ? 29801.424  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15  168104.286 ? 41505.778  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  299282.488 ? 44496.777  ns/op
Finished running test 'micro:java.util.zip.ZipFileOpen'

with patch
Benchmark                       (size)  Mode  Cnt       Score       Error  Units
ZipFileOpen.openCloseZipFile       512  avgt   15   82715.346 ? 21700.950  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15  142253.235 ?  1054.553  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15   77238.320 ?   194.585  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  161828.411 ? 45486.890  ns/op
Finished running test 'micro:java.util.zip.ZipFileOpen'

windows:
without patch:
ZipFileOpen.openCloseZipFile       512  avgt   15  319543.232 ?  46112.481  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15  463719.381 ? 139409.316  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15  750838.029 ? 190726.572  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  875174.035 ? 140971.036  ns/op

with patch:
Benchmark                       (size)  Mode  Cnt       Score        Error  Units
ZipFileOpen.openCloseZipFile       512  avgt   15  400393.718 ? 161890.652  ns/op
ZipFileOpen.openCloseZipFile      1024  avgt   15  380922.933 ?  21776.006  ns/op
ZipFileOpen.openCloseZipFilex2     512  avgt   15  623589.801 ?  38110.510  ns/op
ZipFileOpen.openCloseZipFilex2    1024  avgt   15  774654.146 ?  50413.718  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1767073176

From erikj at openjdk.org  Tue Oct 17 20:04:42 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 17 Oct 2023 20:04:42 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683266663

From lancea at openjdk.org  Tue Oct 17 20:13:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 17 Oct 2023 20:13:48 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v6]
In-Reply-To: <35TteAwG-KgyaZ-o2hdjrz7YinTZMTPPII-WFbg3Los=.266223d5-e336-45c2-8d8d-da626f61de50@github.com>
References: 
 <35TteAwG-KgyaZ-o2hdjrz7YinTZMTPPII-WFbg3Los=.266223d5-e336-45c2-8d8d-da626f61de50@github.com>
Message-ID: 

On Tue, 17 Oct 2023 19:55:19 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove getCanonicalFile calls, update ZipFile jmh benchmark test, tidy up junit test

Latest updates look good.

test/jdk/java/util/zip/ZipFile/ZipSourceCache.java line 103:

> 101:                 // the old Source in use for old file, should no longer map correctly
> 102:                 IOException ioe = assertThrows(IOException.class, () -> readZipFileContents(absoluteZipFile));
> 103:                 assertEquals("ZipFile invalid LOC header (bad signature)", ioe.getMessage());

Perhaps put the expected message in a constant in the event we need to change it at some point it is easier to find

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16115#pullrequestreview-1683270909
PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1362698792

From jlu at openjdk.org  Tue Oct 17 20:14:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Oct 2023 20:14:14 GMT
Subject: RFR: 8318322: Update IANA Language Subtag Registry to Version
 2023-10-16
Message-ID: 

This change updates the IANA subtag registry to the update released on 2023-10-16.

Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/16227/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16227&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318322
  Stats: 53 lines in 2 files changed: 50 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16227/head:pull/16227

PR: https://git.openjdk.org/jdk/pull/16227

From iris at openjdk.org  Tue Oct 17 20:14:47 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 17 Oct 2023 20:14:47 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683283733

From rriggs at openjdk.org  Tue Oct 17 21:35:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Oct 2023 21:35:10 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683418583

From dholmes at openjdk.org  Tue Oct 17 21:35:22 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Oct 2023 21:35:22 GMT
Subject: RFR: 8318126: Refresh manpages
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 23:55:01 GMT, Iris Clark  wrote:

>> The open nroff manpage files are out of sync with their closed markdown sources and need to be refreshed.
>> 
>> The changes to apply are coming from:
>> 
>> - [JDK-8288158](https://bugs.openjdk.org/browse/JDK-8288158): Add an anchor to each subcommand option on jfr html page
>> - [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
>> - [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
>> - [JDK-8308662](https://bugs.openjdk.org/browse/JDK-8308662): Update the "java" tool specification for CompileOnly
>> - [JDK-8317565](https://bugs.openjdk.org/browse/JDK-8317565): Update Manpage for obsoletion of UseSHM
>> - [JDK-8310460](https://bugs.openjdk.org/browse/JDK-8310460): Remove jdeps -profile option
>> 
>> There are also some simple line break changes, likely due to using different versions of the pandoc tool.
>> 
>> Thanks
>
> Marked as reviewed by iris (Reviewer).

Thanks @irisclark !

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

PR Comment: https://git.openjdk.org/jdk/pull/16196#issuecomment-1767198038

From dholmes at openjdk.org  Tue Oct 17 21:35:26 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Oct 2023 21:35:26 GMT
Subject: Integrated: 8318126: Refresh manpages
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 01:18:52 GMT, David Holmes  wrote:

> The open nroff manpage files are out of sync with their closed markdown sources and need to be refreshed.
> 
> The changes to apply are coming from:
> 
> - [JDK-8288158](https://bugs.openjdk.org/browse/JDK-8288158): Add an anchor to each subcommand option on jfr html page
> - [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion
> - [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front
> - [JDK-8308662](https://bugs.openjdk.org/browse/JDK-8308662): Update the "java" tool specification for CompileOnly
> - [JDK-8317565](https://bugs.openjdk.org/browse/JDK-8317565): Update Manpage for obsoletion of UseSHM
> - [JDK-8310460](https://bugs.openjdk.org/browse/JDK-8310460): Remove jdeps -profile option
> 
> There are also some simple line break changes, likely due to using different versions of the pandoc tool.
> 
> Thanks

This pull request has now been integrated.

Changeset: cceb0d8a
Author:    David Holmes 
URL:       https://git.openjdk.org/jdk/commit/cceb0d8a2321ce622569aa4afaf98a074e59e215
Stats:     115 lines in 4 files changed: 27 ins; 64 del; 24 mod

8318126: Refresh manpages

Reviewed-by: alanb, mli, iris

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

PR: https://git.openjdk.org/jdk/pull/16196

From shade at openjdk.org  Tue Oct 17 21:39:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 17 Oct 2023 21:39:11 GMT
Subject: RFR: 8318363: Foreign benchmarks fail to build on some platforms
Message-ID: 

Recent regression, see bug. The fix is to use the proper `jlong <-> ptr` converters.

Additional testing:
 - [x] Build now passes on ARM32
 - [x] Two affected JMH benchmarks still run

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/16228/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16228&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318363
  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16228/head:pull/16228

PR: https://git.openjdk.org/jdk/pull/16228

From almatvee at openjdk.org  Tue Oct 17 21:43:47 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 17 Oct 2023 21:43:47 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 07:04:03 GMT, yaqsun  wrote:

>> on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
>> It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
>> But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.
>
> yaqsun has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed Whitespace error: del tab
>  - 8316563: test tools/jpackage/linux/LinuxResourceTest.java fails on RHEL8 and Fedora 27

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15832#pullrequestreview-1683474813

From srl at openjdk.org  Tue Oct 17 21:48:55 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 17 Oct 2023 21:48:55 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format. To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

This is intentional, because these short names may not be known to users.  Do you have data that ja-JP, zh-CN, de-DE users expect and are familiar with `PST/PDT`?   This is why CLDR fallback rules would fall back to `Los Angeles Time` for example in the longer name. It's not short, but it's understandable, and the numeric offset can work for short. 

I'd encourage engaging with CLDR-TC to discuss the short names upstream if you have data on the recognizability of these short names.   In fact, CLDR probably has _too many_ short names for zones.

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

PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1767240212

From naoto at openjdk.org  Tue Oct 17 22:19:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Oct 2023 22:19:08 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 17 Oct 2023 21:45:57 GMT, Steven Loomis  wrote:

> > CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format. To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
> 
> I added a note to [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979):
> 
> This is intentional, because these short names may not be known to users. Do you have data that ja-JP, zh-CN, de-DE users expect and are familiar with `PST/PDT`? This is why CLDR fallback rules would fall back to `Los Angeles Time` for example in the longer name. It's not short, but it's understandable, and the numeric offset can work for short.

Yes, I am saying not having short names is not a bad thing, or rather better than making up uncommon names among those locals (which COMPAT is doing). GMT offset style is totally acceptable in such cases IMO. In fact, TZ database is getting away from using old three-letter short names.

> I'd encourage engaging with CLDR-TC to discuss the short names upstream if you have data on the recognizability of these short names. In fact, CLDR probably has _too many_ short names for zones.

No, I don't have any data on this. At least I can say that there are no short names for those in Japanese.

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

PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1767274871

From ccheung at openjdk.org  Tue Oct 17 22:51:47 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 17 Oct 2023 22:51:47 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
Message-ID: 

Please review this changeset for adding support for `--module` (-m) option for CDS.
Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.

Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.

Passed tiers 1 - 4 testing.

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

Commit messages:
 - better way to check if a module is a JDK module
 - initial review comments from Ioi
 - 8316969: Improve CDS module graph support for --module option

Changes: https://git.openjdk.org/jdk/pull/16016/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316969
  Stats: 185 lines in 9 files changed: 176 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16016/head:pull/16016

PR: https://git.openjdk.org/jdk/pull/16016

From iklam at openjdk.org  Tue Oct 17 22:51:49 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Oct 2023 22:51:49 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 22:17:34 GMT, Calvin Cheung  wrote:

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

Changes requested by iklam (Reviewer).

src/hotspot/share/classfile/modules.cpp line 597:

> 595:         MetaspaceShared::disable_optimized_module_handling();
> 596:       }
> 597:     }

I think this code can be made less verbose: 

    bool disable = false;
    if (runtime_main_module == nullptr) {
      if (_archived_main_module_name != nullptr) {
        log_info(cds)("Module %s specified during dump time but not during runtime", _archived_main_module_name);
        disable = true;
      }
    } else {
      if (_archived_main_module_name == nullptr) {
        log_info(cds)("Module %s specified during runtime but not during dump time", runtime_main_module);
        disable = true;
      } else if (strcmp(runtime_main_module, _archived_main_module_name) != 0) {
        log_info(cds)("Mismatched modules: runtime %s dump time %s", runtime_main_module, _archived_main_module_name);
        disable = true;
      }
    }

    if (disable) {
      log_info(cds)("Disabling optimized module handling");
      MetaspaceShared::disable_optimized_module_handling();
    }

test/hotspot/jtreg/runtime/cds/appcds/jigsaw/module/ModuleOption.java line 60:

> 58:           .shouldMatch("cds,module.*Restored from archive: entry.0x.*name jdk.compiler");
> 59: 
> 60:         // different module specified during runtime

Maybe add a comment that jdk.httpserver is special as it specifies its main class, so it causes a different code path to be used in ModuleBootstrap than jdk.compiler?

Also, maybe add an additional test case with `-m jdk.httpserver` (without specifying the main class).

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

PR Review: https://git.openjdk.org/jdk/pull/16016#pullrequestreview-1660271426
PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1347686444
PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1347690405

From alanb at openjdk.org  Tue Oct 17 22:51:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 22:51:49 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 22:17:34 GMT, Calvin Cheung  wrote:

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 239:

> 237:                        // only consider modules from JDK
> 238:                        (mainModule.startsWith("jdk.") || mainModule.startsWith("java."))) {
> 239:                     canArchive = true;

This will require discussion as there may be modules in the run-time image that start with other names.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 483:

> 481:         // Archive module graph and boot layer can be archived at CDS dump time.
> 482:         // Only allow the unnamed module case for now.
> 483:         if (canArchive) {

Doesn't this invalidate the comments?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1343607473
PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1343609766

From ccheung at openjdk.org  Tue Oct 17 22:51:49 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 17 Oct 2023 22:51:49 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 3 Oct 2023 07:11:54 GMT, Alan Bateman  wrote:

>> Please review this changeset for adding support for `--module` (-m) option for CDS.
>> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
>> 
>> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
>> 
>> Passed tiers 1 - 4 testing.
>
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 239:
> 
>> 237:                        // only consider modules from JDK
>> 238:                        (mainModule.startsWith("jdk.") || mainModule.startsWith("java."))) {
>> 239:                     canArchive = true;
> 
> This will require discussion as there may be modules in the run-time image that start with other names.

It would be nice if there's another way to find out if a module is from JDK.

> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 483:
> 
>> 481:         // Archive module graph and boot layer can be archived at CDS dump time.
>> 482:         // Only allow the unnamed module case for now.
>> 483:         if (canArchive) {
> 
> Doesn't this invalidate the comments?

I'll update the comment in my next update.
I've just pushed a commit based on some offline discussion with Ioi.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1346118458
PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1346119507

From iklam at openjdk.org  Tue Oct 17 22:51:49 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Oct 2023 22:51:49 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 4 Oct 2023 15:59:54 GMT, Calvin Cheung  wrote:

>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 239:
>> 
>>> 237:                        // only consider modules from JDK
>>> 238:                        (mainModule.startsWith("jdk.") || mainModule.startsWith("java."))) {
>>> 239:                     canArchive = true;
>> 
>> This will require discussion as there may be modules in the run-time image that start with other names.
>
> It would be nice if there's another way to find out if a module is from JDK.

When a named module is created, we know its location, which is also passed to the C code and stored inside the C++ `ModuleEntry` data structure.

https://github.com/openjdk/jdk/blob/a1c9587c27538bda3b0f6745d9c80ff4e1b9a77e/src/java.base/share/classes/java/lang/Module.java#L128-L150

Maybe we can add a new native method `jdk.internal.misc.CDS.isBuiltinModule(Module m)` which tests if `ModuleEntry::_location` starts with `"jrt:"`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1347681387

From alanb at openjdk.org  Tue Oct 17 22:51:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Oct 2023 22:51:49 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 5 Oct 2023 16:18:57 GMT, Ioi Lam  wrote:

> Maybe we can add a new native method `jdk.internal.misc.CDS.isBuiltinModule(Module m)` which tests if `ModuleEntry::_location` starts with `"jrt:"`?

There isn't any really notion of "built-in module", they may be modules in the run-time image that start with names such than "java." or "jdk.".  Are you just looking to know if the module is in the run-time image and hasn't been upgraded?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1348280322

From ccheung at openjdk.org  Tue Oct 17 22:51:49 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 17 Oct 2023 22:51:49 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 6 Oct 2023 06:09:50 GMT, Alan Bateman  wrote:

>> When a named module is created, we know its location, which is also passed to the C code and stored inside the C++ `ModuleEntry` data structure.
>> 
>> https://github.com/openjdk/jdk/blob/a1c9587c27538bda3b0f6745d9c80ff4e1b9a77e/src/java.base/share/classes/java/lang/Module.java#L128-L150
>> 
>> Maybe we can add a new native method `jdk.internal.misc.CDS.isBuiltinModule(Module m)` which tests if `ModuleEntry::_location` starts with `"jrt:"`?
>
>> Maybe we can add a new native method `jdk.internal.misc.CDS.isBuiltinModule(Module m)` which tests if `ModuleEntry::_location` starts with `"jrt:"`?
> 
> There isn't any really notion of "built-in module", they may be modules in the run-time image that start with names such than "java." or "jdk.".  Are you just looking to know if the module is in the run-time image and hasn't been upgraded?

I've found a way to determine if a module is from the runtime image by checking the module's `location` and the `scheme` of the `location` is "jrt". All done at the java level. Please refer to my latest push with update on the ModuleBootstrap.java.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1362892360

From abimpoudis at openjdk.org  Tue Oct 17 23:12:19 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 23:12:19 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v6]
In-Reply-To: 
References: 
Message-ID: 

> This PR finalizes the feature of unnamed variables and patterns.

Aggelos Biboudis has updated the pull request with a new target base 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 unnamed
 - Merge branch 'master' into unnamed
 - Add test with multi-catch
 - Merge branch 'master' into unnamed
 - Address review by @mcimadamore
 - Address review by @lahodaj
 - 8315532: Compiler Implementation for Unnamed Variables and Patterns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/13a4b6f8..067e358c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=04-05

  Stats: 2480 lines in 135 files changed: 1806 ins; 306 del; 368 mod
  Patch: https://git.openjdk.org/jdk/pull/15649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649

PR: https://git.openjdk.org/jdk/pull/15649

From abimpoudis at openjdk.org  Tue Oct 17 23:12:46 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 23:12:46 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v23]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <32O0ulOuwl-JFnnLg0056h_56Ovbc8B3tKqBlg-MISM=.98ed6a51-53e4-4f8e-927a-6b61a1ed9daf@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Improve javadoc of ExactConversionsSupport
   
   Co-authored-by: Raffaello Giulietti 
 - Adjust javadoc on ExactConversionsSupport
 - Merge branch 'master' into primitive-patterns
 - Address review
   
   - Add comments
   - Rename exactness methods
   - Use convenience methods from TypeTag for checkUnconditionallyExactPrimitives in Types
   - Port isStrictSubRangeOf to Wrapper and use it for unconditionalExactnessCheck in SwitchBootstraps
 - Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
 - Merge branch 'master' into primitive-patterns
 - Update name of exactness methods class
 - Merge branch 'master' into primitive-patterns
 - Adjust tests
   
   Co-authored-by: Jan Lahoda 
   Co-authored-by: Angelos Bimpoudis 
 - ... and 19 more: https://git.openjdk.org/jdk/compare/61a05796...4acb66e0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/b9237148..4acb66e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=21-22

  Stats: 3033 lines in 152 files changed: 2010 ins; 411 del; 612 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From iklam at openjdk.org  Tue Oct 17 23:44:48 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Oct 2023 23:44:48 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 22:17:34 GMT, Calvin Cheung  wrote:

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

src/hotspot/share/classfile/modules.cpp line 567:

> 565: #endif
> 566: 
> 567: void Modules::dump_module_name() {

This function should be `dump_main_module_name()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1362928947

From naoto at openjdk.org  Tue Oct 17 23:48:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Oct 2023 23:48:46 GMT
Subject: RFR: 8318322: Update IANA Language Subtag Registry to Version
 2023-10-16
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu  wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16227#pullrequestreview-1683655344

From duke at openjdk.org  Wed Oct 18 01:22:51 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 18 Oct 2023 01:22:51 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: <0GO4Vo0XtxBy3CpeFxIX3Jo9siV-PrYOZhGJ0gU-MmI=.eceeb6c4-1581-40df-8a17-9f8fb9c70be9@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 <0GO4Vo0XtxBy3CpeFxIX3Jo9siV-PrYOZhGJ0gU-MmI=.eceeb6c4-1581-40df-8a17-9f8fb9c70be9@github.com>
Message-ID: 

On Tue, 17 Oct 2023 15:56:58 GMT, Chen Liang  wrote:

> Can you export jfr recordings of two different runs to check?

How to do this? I don't know how yet

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1767448022

From liach at openjdk.org  Wed Oct 18 01:30:48 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 18 Oct 2023 01:30:48 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: <4tDBW2kmLDkpLtzFXOBhoEmTsABCu8dUiibtK6F28R4=.49da9031-3cce-430d-a226-40f1721ef522@github.com>

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

In the jvm args for your benchmark, add `-XX:StartFlightRecording=filename=.jfr`
When you have that flag, you just need one run, as subsequent runs will override the existing jfr recording.
If you have jfr for both a slow and a fast run, you can use VisualVM to see their CPU time differences. It's just JDK's builtin profiler.

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1767454580

From duke at openjdk.org  Wed Oct 18 02:21:50 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 18 Oct 2023 02:21:50 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

* use recipe ("\1.\1\1") branch : https://github.com/wenshao/jdk/tree/optim_decimal_to_string_x1_jfr


Running test 'micro:java.math.BigDecimals.testSmallToEngineeringString'
# JMH version: 1.37
# VM version: JDK 22-internal, OpenJDK 64-Bit Server VM, 22-internal-adhoc.wenshao.jdk
# VM invoker: /Users/wenshao/Work/git/jdk/build/macosx-aarch64-server-release/images/jdk/bin/java
# VM options: -Djava.library.path=/Users/wenshao/git/jdk/build/macosx-aarch64-server-release/images/test/micro/native -XX:StartFlightRecording=filename=flight_dec.jfr
# Blackhole mode: compiler (auto-detected, use -Djmh.blackhole.autoDetect=false to disable)
# Warmup: 5 iterations, 1 s each
# Measurement: 5 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.openjdk.bench.java.math.BigDecimals.testSmallToEngineeringString

# Run progress: 0.00% complete, ETA 00:00:30
# Fork: 1 of 3
[0.294s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default.
[0.294s][info][jfr,startup] 
[0.294s][info][jfr,startup] Use jcmd 90487 JFR.dump name=1 to copy recording data to file.
# Warmup Iteration   1: 14.387 ns/op
# Warmup Iteration   2: 13.387 ns/op
# Warmup Iteration   3: 12.925 ns/op
# Warmup Iteration   4: 12.941 ns/op
# Warmup Iteration   5: 12.873 ns/op
Iteration   1: 12.872 ns/op
Iteration   2: 12.893 ns/op
Iteration   3: 12.978 ns/op
Iteration   4: 12.834 ns/op
Iteration   5: 12.878 ns/op

# Run progress: 33.33% complete, ETA 00:00:22
# Fork: 2 of 3
[0.299s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default.
[0.299s][info][jfr,startup] 
[0.299s][info][jfr,startup] Use jcmd 5809 JFR.dump name=1 to copy recording data to file.
# Warmup Iteration   1: 19.515 ns/op
# Warmup Iteration   2: 17.993 ns/op
# Warmup Iteration   3: 17.739 ns/op
# Warmup Iteration   4: 17.687 ns/op
# Warmup Iteration   5: 17.720 ns/op
Iteration   1: 17.780 ns/op
Iteration   2: 17.526 ns/op
Iteration   3: 17.857 ns/op
Iteration   4: 17.667 ns/op
Iteration   5: 17.697 ns/op

# Run progress: 66.67% complete, ETA 00:00:11
# Fork: 3 of 3
[0.282s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default.
[0.282s][info][jfr,startup] 
[0.282s][info][jfr,startup] Use jcmd 20436 JFR.dump name=1 to copy recording data to file.
# Warmup Iteration   1: 14.122 ns/op
# Warmup Iteration   2: 12.530 ns/op
# Warmup Iteration   3: 12.472 ns/op
# Warmup Iteration   4: 12.479 ns/op
# Warmup Iteration   5: 12.501 ns/op
Iteration   1: 12.552 ns/op
Iteration   2: 12.583 ns/op
Iteration   3: 12.549 ns/op
Iteration   4: 12.487 ns/op
Iteration   5: 12.530 ns/op


Result "org.openjdk.bench.java.math.BigDecimals.testSmallToEngineeringString":
  14.379 ?(99.9%) 2.609 ns/op [Average]
  (min, avg, max) = (12.487, 14.379, 17.857), stdev = 2.440
  CI (99.9%): [11.770, 16.988] (assumes normal distribution)

[flight_dec.jfr.zip](https://github.com/openjdk/jdk/files/12974447/flight_dec.jfr.zip)

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

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1767505819

From jvernee at openjdk.org  Wed Oct 18 03:58:43 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 03:58:43 GMT
Subject: RFR: 8318363: Foreign benchmarks fail to build on some platforms
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 21:23:38 GMT, Aleksey Shipilev  wrote:

> Recent regression, see bug. The fix is to use the proper `jlong <-> ptr` converters.
> 
> Additional testing:
>  - [x] Build now passes on ARM32
>  - [x] Two affected JMH benchmarks still run

Thanks for fixing. I Suppose these benchmarks are not built in GitHub actions.

test/micro/org/openjdk/bench/java/lang/foreign/libToCString.c line 24:

> 22:  */
> 23: 
> 24: #include 

I think you just want `jlong.h` here? AFAIK the `jlong_md.h` is the platform specific implementation file, whereas `jlong.h` is the 'interface'.

(though, `jlong.h` just includes `jlong_md.h` so it probably doesn't really matter in practice)

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16228#pullrequestreview-1683935665
PR Review Comment: https://git.openjdk.org/jdk/pull/16228#discussion_r1363135178

From jvernee at openjdk.org  Wed Oct 18 04:21:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 04:21:33 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native code
Message-ID: 

Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.

The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.

Components of this patch:

- New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
- Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
- `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
- `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
- The object/oop + offset is exposed as temporary address to native code.
- Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
- Only x64 and AArch64 for now.
- I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
- I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
- Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`

Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.

Numbers for the included benchmark on my machine are:


Benchmark                     (size)  Mode  Cnt        Score       Error  Units
CriticalCalls.callNotPinned      100  avgt   30      123.060 ?     5.674  ns/op
CriticalCalls.callNotPinned    10000  avgt   30     3136.032 ?    46.175  ns/op
CriticalCalls.callNotPinned  1000000  avgt   30  1190692.161 ? 36254.502  ns/op
CriticalCalls.callPinned         100  avgt   30       30.722 ?     0.298  ns/op
CriticalCalls.callPinned       10000  avgt   30     2233.453 ?    23.568  ns/op
CriticalCalls.callPinned     1000000  avgt   30   220870.350 ?  1576.958  ns/op
CriticalCalls.callRecycled       100  avgt   30       38.753 ?     0.269  ns/op
CriticalCalls.callRecycled     10000  avgt   30     2683.381 ?    56.335  ns/op
CriticalCalls.callRecycled   1000000  avgt   30   314389.106 ?  5275.236  ns/op


In particular the difference between the `callNotPinned`, which allocates a native segment and copies the heap segment into it, and the `callPinned` which is zero allocation and zero copy, is important. While the allocation can sometimes be avoided (`callRecycled`), sometimes the API's structure prevents allocations from being amortized.

Testing: `jdk_foreign`

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

Commit messages:
 - eyeball more fixes
 - ref other platforms + add back shuffle reg
 - fix failing x86 test
 - fix arm stubs
 - fix x86_32 stubs
 - Share DowncallStubGenerator impl between x64 and aarch64
 - remove GCLocker calls
 - fix zero compilation + disable stress test on non-debug because of missing CheckUnhandledOops flag
 - fix zero for real
 - fix zero + clang build
 - ... and 18 more: https://git.openjdk.org/jdk/compare/1d54e73f...90fdbec0

Changes: https://git.openjdk.org/jdk/pull/16201/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8254693
  Stats: 1969 lines in 60 files changed: 1169 ins; 545 del; 255 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From jvernee at openjdk.org  Wed Oct 18 04:21:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 04:21:35 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code
In-Reply-To: 
References: 
Message-ID: <7fdZdmxHUrXdcurmlKY1-gwfWNEPLcU9Pijk_DC1ntY=.2deb3ecd-52e1-416a-ae33-7f0bb1e8e0e8@github.com>

On Mon, 16 Oct 2023 10:19:17 GMT, Jorn Vernee  wrote:

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

@TheRealMDoerr @feilongjiang @sid8606 

I've kept things working as best as possible on PPC, RISC-V, and s390x. But, more changes are needed to actually implement the new feature on those platforms. (See the changes to `downcallLinker_aarch64.cpp` and `CallArranger`).

test/jdk/java/foreign/critical/TestCritical.java line 93:

> 91: 
> 92:     @Test(dataProvider = "allowHeapCases")
> 93:     public void testAllowHeap(AllowHeapCase testCase) throws Throwable {

Note that this is the only new test. The diff looks bigger because I've renamed the enclosing directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1767610566
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1360478619

From jvernee at openjdk.org  Wed Oct 18 04:44:26 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 04:44:26 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  drop unused in_reg_spiller

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/90fdbec0..2c073bf1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From dholmes at openjdk.org  Wed Oct 18 05:35:46 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Oct 2023 05:35:46 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <-mnRIhYxnLvgUVnwxr_thupKgzfav_NdaT79AS1PO7M=.7cb2174c-9808-42ea-beb7-312ebab3e683@github.com>

On Mon, 16 Oct 2023 15:04:51 GMT, Matthias Baesken  wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   windows aarch64 build issues
>
> Hello, any comments about the idea of calling into 'os::dll_load' instead ? That would indeed make the coding smaller and less 'messy' .

@MBaesken I'm not at all sure what it would look like - sorry. But there doesn't seem to be any general support from the library folk for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1767673904

From iris at openjdk.org  Wed Oct 18 05:36:43 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Oct 2023 05:36:43 GMT
Subject: RFR: 8318322: Update IANA Language Subtag Registry to Version
 2023-10-16
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu  wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16227#pullrequestreview-1684058244

From duke at openjdk.org  Wed Oct 18 05:44:30 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 18 Oct 2023 05:44:30 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v2]
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: 

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix from @rgiulietti 's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/bce554a8..fd5a5f29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=00-01

  Stats: 69 lines in 3 files changed: 50 ins; 13 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15776/head:pull/15776

PR: https://git.openjdk.org/jdk/pull/15776

From pminborg at openjdk.org  Wed Oct 18 06:22:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 06:22:48 GMT
Subject: RFR: 8317870: Add @sealedGraph to Thread.Builder
In-Reply-To: <2SvM6WuryGqupwuufSaGMKMEOadhn8kCDQSe9wIiX_w=.4d7d5432-0357-47bc-9432-396a6e544758@github.com>
References: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>
 <2SvM6WuryGqupwuufSaGMKMEOadhn8kCDQSe9wIiX_w=.4d7d5432-0357-47bc-9432-396a6e544758@github.com>
Message-ID: 

On Wed, 11 Oct 2023 15:00:03 GMT, Alan Bateman  wrote:

>> This PR proposes to Add @sealedGraph to `Thread.Builder`.
>
> @pron Do you have any comment on this one? I remember we decided not to do this in JDK 21.

@AlanBateman and @pron : Should we drop this PR? I will lazily do that in a week or so unless you otherwise comment here.

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

PR Comment: https://git.openjdk.org/jdk/pull/16138#issuecomment-1767741857

From pminborg at openjdk.org  Wed Oct 18 06:23:47 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 06:23:47 GMT
Subject: RFR: 8317868: Add @sealedGraph to MethodHandleDesc and descendants
 [v2]
In-Reply-To: 
References: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
 
Message-ID: <6gcaJjcbPkwlB8LUZG2b6LmBlPv6olRzV1VeG0Cz3gI=.bff4bd39-96f0-4738-baea-6f2a57358d18@github.com>

On Wed, 11 Oct 2023 11:18:41 GMT, Per Minborg  wrote:

>> This PR proposes to add  @sealedGraph to MethodHandleDesc and descendants.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Revoke change in DMHD

Any reviewers on this very small PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16137#issuecomment-1767744163

From alanb at openjdk.org  Wed Oct 18 06:28:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Oct 2023 06:28:46 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
In-Reply-To: 
References: 
Message-ID: 

On Mon, 2 Oct 2023 22:17:34 GMT, Calvin Cheung  wrote:

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 472:

> 470: 
> 471:         // if -Xshare:dump and mainModule are specified, check if the mainModule
> 472:         // is a builtin JDK module. If so, set canArchive to true so that the

There is no notion of "built-in JDK module" so I think change the comment to say that it checks if the main module is in the run-time image and not on the upgrade module path.

URI schemes are compared without regard to case so it should be equalsIgnoreCase("jrt").

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1363314822

From kyukihiro at openjdk.org  Wed Oct 18 08:15:38 2023
From: kyukihiro at openjdk.org (Kimura Yukihiro)
Date: Wed, 18 Oct 2023 08:15:38 GMT
Subject: RFR: 8318410: [TESTBUG]
 jdk/java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Japanese
 Windows
Message-ID: 

I would like to fix this issue
because the test dose not work as intended.
Could someone please review it? 

Thanks,
Kimura Yukihiro

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

Commit messages:
 - 8318410: [TESTBUG] jdk/java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Japanese Windows

Changes: https://git.openjdk.org/jdk/pull/16235/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318410
  Stats: 39 lines in 2 files changed: 20 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/16235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16235/head:pull/16235

PR: https://git.openjdk.org/jdk/pull/16235

From pminborg at openjdk.org  Wed Oct 18 08:18:30 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 08:18:30 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v2]
In-Reply-To: 
References: 
Message-ID: <0qEpV-UB_LosNpBS5KX2yw7l6UEijnWCuT3ZJyqihmg=.a341e91e-39b4-47e2-84ab-1a639d9db2ff@github.com>

> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
> 
> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
> 
> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
> 
> 
> // Resolve ambiguity
> var function = Function.of(String::isEmpty); // Function
> var predicate = Predicate.of(String::isEmpty); // Predicate
> 
> // Fluent composition
> var chained = Function.of(String::length)       // Function
>                    .andThen(Integer::byteValue);      // Function
> 
> 
> Please see the original bug report for a comprehensive description of these proposed changes.
> 
> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
> 
> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add co/contra variance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16213/files
  - new: https://git.openjdk.org/jdk/pull/16213/files/dbfb4008..96586f7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16213&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16213&range=00-01

  Stats: 34 lines in 7 files changed: 21 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/16213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16213/head:pull/16213

PR: https://git.openjdk.org/jdk/pull/16213

From fyang at openjdk.org  Wed Oct 18 08:29:38 2023
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Oct 2023 08:29:38 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 17 Oct 2023 09:52:15 GMT, Ilya Gavrilin  wrote:

>> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1682:
>> 
>>> 1680:   // use floating-point 1.0 with a sign of input
>>> 1681:   is_double ? fsgnj_d(dst, one, src)
>>> 1682:             : fsgnj_s(dst, one, src);
>> 
>> What if the `src` argument contains zero? Math.signum(float/double) is supposed to return zero if the argument is zero [1].
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2602
>
> According to IEEE754, we can get positive or negative zero in the `src` register (also positive zero can be named as zero) , and these cases included to mask for the tmp1 (L1671-1676) and `src` value returned.

I see. Thanks for the answer. I can approve this once my other comments are resolved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1363440282

From shade at openjdk.org  Wed Oct 18 08:30:37 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 18 Oct 2023 08:30:37 GMT
Subject: RFR: 8318363: Foreign benchmarks fail to build on some platforms
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Recent regression, see bug. The fix is to use the proper `jlong <-> ptr` converters.
> 
> Additional testing:
>  - [x] Build now passes on ARM32
>  - [x] Two affected JMH benchmarks still run

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Use jlong.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16228/files
  - new: https://git.openjdk.org/jdk/pull/16228/files/cfa2ee07..8d9d474a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16228&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16228&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16228/head:pull/16228

PR: https://git.openjdk.org/jdk/pull/16228

From shade at openjdk.org  Wed Oct 18 08:30:41 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 18 Oct 2023 08:30:41 GMT
Subject: RFR: 8318363: Foreign benchmarks fail to build on some platforms
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <2W9z4r-ehKKsFXPzz4tPuzZpRBb-dN53V6IXCxnBFOs=.bf1fa013-045a-4341-a0c3-ee1c91ca609b@github.com>

On Wed, 18 Oct 2023 03:54:17 GMT, Jorn Vernee  wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use jlong.h
>
> test/micro/org/openjdk/bench/java/lang/foreign/libToCString.c line 24:
> 
>> 22:  */
>> 23: 
>> 24: #include 
> 
> I think you just want `jlong.h` here? AFAIK the `jlong_md.h` is the platform specific implementation file, whereas `jlong.h` is the 'interface'.
> 
> (though, `jlong.h` just includes `jlong_md.h` so it probably doesn't really matter in practice)

Right. I copy-pasted from some other file that includes `jlong_md.h` instead of `jlong.h`. For cleanliness reasons, we should of course include `jlong.h`. Fixed in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16228#discussion_r1363461316

From pminborg at openjdk.org  Wed Oct 18 08:33:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 08:33:34 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
> 
> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
> 
> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
> 
> 
> // Resolve ambiguity
> var function = Function.of(String::isEmpty); // Function
> var predicate = Predicate.of(String::isEmpty); // Predicate
> 
> // Fluent composition
> var chained = Function.of(String::length)       // Function
>                    .andThen(Integer::byteValue);      // Function
> 
> 
> Please see the original bug report for a comprehensive description of these proposed changes.
> 
> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
> 
> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update naming and javadocs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16213/files
  - new: https://git.openjdk.org/jdk/pull/16213/files/96586f7e..028c3054

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16213&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16213&range=01-02

  Stats: 75 lines in 8 files changed: 17 ins; 0 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/16213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16213/head:pull/16213

PR: https://git.openjdk.org/jdk/pull/16213

From pminborg at openjdk.org  Wed Oct 18 08:33:37 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 08:33:37 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 13:22:29 GMT, Raffaello Giulietti  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update naming and javadocs
>
> src/java.base/share/classes/java/util/function/BiConsumer.java line 105:
> 
>> 103:      */
>> 104:     static  BiConsumer of(BiConsumer uncaptured) {
>> 105:         return Objects.requireNonNull(uncaptured);
> 
> This does more than just capturing: not sure if the `null` check is generally useful here and elsewhere.

I have added a `@throws NullPointerException if source is null` clause where needed. I think there is no valid use case for providing null as a parameter and so I believe this is a desired property of the contemplated methods. However, there might be contrary arguments that I have not seen?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1363455782

From mbaesken at openjdk.org  Wed Oct 18 08:44:35 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 18 Oct 2023 08:44:35 GMT
Subject: RFR: JDK-8318415: Adjust describing comment of os_getChildren after
 8315026
Message-ID: <8pQJPDwoYZ69TAln8NHL8WnuD8Ts0dkR9jC5jxrZL7o=.1c6793df-94f5-4c37-8e7a-ea47e8408cdd@github.com>

8315026 adjusted and improved the describings comments already for AIX/Linux. But macOS was not adjusted.

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

Commit messages:
 - JDK-8318415

Changes: https://git.openjdk.org/jdk/pull/16236/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16236&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318415
  Stats: 15 lines in 2 files changed: 8 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16236.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16236/head:pull/16236

PR: https://git.openjdk.org/jdk/pull/16236

From pminborg at openjdk.org  Wed Oct 18 08:55:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 08:55:49 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
> 
> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
> 
> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
> 
> 
> // Resolve ambiguity
> var function = Function.of(String::isEmpty); // Function
> var predicate = Predicate.of(String::isEmpty); // Predicate
> 
> // Fluent composition
> var chained = Function.of(String::length)       // Function
>                    .andThen(Integer::byteValue);      // Function
> 
> 
> Please see the original bug report for a comprehensive description of these proposed changes.
> 
> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
> 
> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add caution about method references

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16213/files
  - new: https://git.openjdk.org/jdk/pull/16213/files/028c3054..f4027948

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16213&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16213&range=02-03

  Stats: 133 lines in 9 files changed: 132 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16213/head:pull/16213

PR: https://git.openjdk.org/jdk/pull/16213

From pminborg at openjdk.org  Wed Oct 18 09:00:09 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 09:00:09 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v5]
In-Reply-To: 
References: 
Message-ID: <3ntu2qv_pOdX5bQm01UhCTZ2rSvp6REJ6_tghzYxQIA=.94354eb1-ffbc-4bff-951f-2cb887a3f414@github.com>

> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
> 
> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
> 
> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
> 
> 
> // Resolve ambiguity
> var function = Function.of(String::isEmpty); // Function
> var predicate = Predicate.of(String::isEmpty); // Predicate
> 
> // Fluent composition
> var chained = Function.of(String::length)       // Function
>                    .andThen(Integer::byteValue);      // Function
> 
> 
> Please see the original bug report for a comprehensive description of these proposed changes.
> 
> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
> 
> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Pretty

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16213/files
  - new: https://git.openjdk.org/jdk/pull/16213/files/f4027948..9054328a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16213&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16213&range=03-04

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16213/head:pull/16213

PR: https://git.openjdk.org/jdk/pull/16213

From jvernee at openjdk.org  Wed Oct 18 08:59:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 08:59:41 GMT
Subject: RFR: 8318363: Foreign benchmarks fail to build on some platforms
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 08:30:37 GMT, Aleksey Shipilev  wrote:

>> Recent regression, see bug. The fix is to use the proper `jlong <-> ptr` converters.
>> 
>> Additional testing:
>>  - [x] Build now passes on ARM32
>>  - [x] Two affected JMH benchmarks still run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jlong.h

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16228#pullrequestreview-1684501179

From liach at openjdk.org  Wed Oct 18 09:14:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 18 Oct 2023 09:14:52 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 08:22:05 GMT, Per Minborg  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pretty
>
> src/java.base/share/classes/java/util/function/UnaryOperator.java line 68:
> 
>> 66:      * @see Function#andThen(Function)
>> 67:      */
>> 68:     default UnaryOperator andThenUnary(UnaryOperator after) {
> 
> What are your comments on this proposed method?

Just curious, do we have any idea how extensively `UnaryOperator` is used as a parameter type in user code compared to plain `Function`? If it's not preferred over `Function`, this new method might not be very useful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1363531469

From pminborg at openjdk.org  Wed Oct 18 09:25:05 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 09:25:05 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 09:12:23 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/util/function/UnaryOperator.java line 68:
>> 
>>> 66:      * @see Function#andThen(Function)
>>> 67:      */
>>> 68:     default UnaryOperator andThenUnary(UnaryOperator after) {
>> 
>> What are your comments on this proposed method?
>
> Just curious, do we have any idea how extensively `UnaryOperator` is used as a parameter type in user code compared to plain `Function`? If it's not preferred over `Function`, this new method might not be very useful.

Generally speaking, there are 1,594 usages of `Function` and 208 usages of `UnaryFunction` in the JDK itself. More specifically, there are 8 usages of `Function::andThen` and zero use of `UnaryOperator::andThen` in the JDK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1363544378

From mcimadamore at openjdk.org  Wed Oct 18 09:25:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 09:25:09 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 04:44:26 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop unused in_reg_spiller

src/java.base/share/classes/java/lang/foreign/Linker.java line 792:

> 790:          * such as loss of performance, or JVM crashes.
> 791:          * 

> 792:          * Critical functions can optionally allow access to the Java heap. This allows a client to pass heap

Suggestion:

         * Critical functions can optionally allow access to the Java heap. This allows clients to pass heap

src/java.base/share/classes/java/lang/foreign/Linker.java line 795:

> 793:          * memory segments as addresses, where normally only off-heap memory segments would be allowed. The memory region
> 794:          * inside the Java heap is exposed through a temporary native address that is valid for the duration of the
> 795:          * function call. As such, these temporary addresses, or any addresses derived from them, should not be used

The API does not expose temporary addresses - so it is not 100% clear when reading what this para refers to. I suppose you mean a native function that "captures" an object's address and then returns it, so that the client wraps it in a zero-length memory segment? I can't decide on top of my head if this is too cornery or not, even for this javadoc.

src/java.base/share/classes/java/lang/foreign/Linker.java line 800:

> 798:          * prohibitive in terms of performance.
> 799:          *
> 800:          * @implNote As a consequence of allowing heap access, the JVM will either lock the garbage collector, or pin the

This is a very low-level comment. Which is fine per se. But it doesn't say what does it mean for the developer using this functionality. I think you want to say that GC is impacted in some way or form. If so, please say that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363538621
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363541304
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363544042

From jvernee at openjdk.org  Wed Oct 18 09:32:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 09:32:09 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 09:20:10 GMT, Maurizio Cimadamore  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   drop unused in_reg_spiller
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 795:
> 
>> 793:          * memory segments as addresses, where normally only off-heap memory segments would be allowed. The memory region
>> 794:          * inside the Java heap is exposed through a temporary native address that is valid for the duration of the
>> 795:          * function call. As such, these temporary addresses, or any addresses derived from them, should not be used
> 
> The API does not expose temporary addresses - so it is not 100% clear when reading what this para refers to. I suppose you mean a native function that "captures" an object's address and then returns it, so that the client wraps it in a zero-length memory segment? I can't decide on top of my head if this is too cornery or not, even for this javadoc.

I'm not sure what to write to make this clearer. The address that is exposed to the native target function is indeed a temporary address that is constructed from the oop and offset. It is temporary because after the native call, the GC might move the object around, which invalidates the address.

This part is meant to document that native code should not be holding on to the address until after the call completes. This also includes returning the address back to Java. The address would be invalid the moment the function returns.

Would it help if this said: `The memory region inside the Java heap is exposed to the native target function through a temporary native address`?

> src/java.base/share/classes/java/lang/foreign/Linker.java line 800:
> 
>> 798:          * prohibitive in terms of performance.
>> 799:          *
>> 800:          * @implNote As a consequence of allowing heap access, the JVM will either lock the garbage collector, or pin the
> 
> This is a very low-level comment. Which is fine per se. But it doesn't say what does it mean for the developer using this functionality. I think you want to say that GC is impacted in some way or form. If so, please say that.

This comment can be removed, as we no longer lock the GC. The same restrictions apply as a 'regular' critical call that does not allow passing heap segments. The call should complete quickly.

> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 281:
> 
>> 279:     }
>> 280: 
>> 281:     static SegmentOffset segmentOffsetAllowHeap() {
> 
> I suppose `heapSegmentOffset` is not good because this binding applies to both native and heap segments, right?

Yes. Setting `allowHeap` to true, just allows heap segments to be used, by switching the object + offset addressing pairs. Native segments are also handled by addressing pair. So this binding applies to both.

FWIW, we don't allow heap segments for critical calls by default, since it complicates the calling convention and the work the downcall stub does, which would be detrimental to performance in a case that only needs support off-heap segments. (and when we're talking about critical calls, every nanosecond counts)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363551493
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363553663
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363554288

From mcimadamore at openjdk.org  Wed Oct 18 09:32:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 09:32:12 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
Message-ID: <4JaIjJ4E_HG1DLJLX_LvL4ysvZsyT6HZxQOPFAJl2uU=.415cf6c9-4e42-4501-a6fb-5e914fd98877@github.com>

On Wed, 18 Oct 2023 04:44:26 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop unused in_reg_spiller

src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 205:

> 203:                    LoadFunc loadFunc, SegmentAllocator allocator);
> 204: 
> 205:     private static void checkType(Class type) {

For another day: I wonder if we might be better served by more specific "check" routines. E.g. I suppose `Object` is not valid always... and maybe in other cases only certain primitives are ok.

src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 281:

> 279:     }
> 280: 
> 281:     static SegmentOffset segmentOffsetAllowHeap() {

I suppose `heapSegmentOffset` is not good because this binding applies to both native and heap segments, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363547594
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363552900

From jvernee at openjdk.org  Wed Oct 18 09:38:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 09:38:55 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v3]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  fix s390 & riscv compilation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/2c073bf1..20fc7fa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From mcimadamore at openjdk.org  Wed Oct 18 09:39:01 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 09:39:01 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
Message-ID: <4Zl8qpBRu9L-zLZ--FcK3ADw-LTuqwX7l7-AxxFhQZA=.675541a1-6933-42fb-bec8-14d0d531902f@github.com>

On Wed, 18 Oct 2023 04:44:26 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop unused in_reg_spiller

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java line 156:

> 154: 
> 155:         BindingCalculator argCalc = forUpcall ? new BoxBindingCalculator(true) : new UnboxBindingCalculator(true, forVariadicFunction, options.allowsHeapAccess());
> 156:         BindingCalculator retCalc = forUpcall ? new UnboxBindingCalculator(false, forVariadicFunction, false) : new BoxBindingCalculator(false);

asymmetry noted - that said, not much that can be done here - as for an upcall it is not clear what the surrounding context is (e.g. where's the place where unpinning happens)

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java line 188:

> 186:                     acquiredSessions.add(sessionImpl);
> 187:                     if (invData.allowsHeapAccess() && !ms.isNative()) {
> 188:                         heapBases[i] = ms.heapBase().get();

This will fail if the segment is read-only. Use the unsafe variant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363562390
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363566076

From jvernee at openjdk.org  Wed Oct 18 09:42:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 09:42:27 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v4]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Phrasing
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/20fc7fa1..c4a8866b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From mcimadamore at openjdk.org  Wed Oct 18 09:48:34 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 09:48:34 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 04:44:26 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop unused in_reg_spiller

test/micro/org/openjdk/bench/java/lang/foreign/CriticalCalls.java line 101:

> 99:     public int callNotPinned() throws Throwable {
> 100:         try (Arena arena = Arena.ofConfined()) {
> 101:             MemorySegment nativeArr = arena.allocate(JAVA_INT, arr.length);

This allocation method will zero the segment. I think that's a bit unfair and will bias the results against non-pinned, right?

test/micro/org/openjdk/bench/java/lang/foreign/CriticalCalls.java line 110:

> 108:     public int callRecycled() throws Throwable {
> 109:         MemorySegment nativeArr = recycler.allocate(JAVA_INT, arr.length);
> 110:         MemorySegment.copy(arr, 0, nativeArr, JAVA_INT, 0, arr.length);

Same here - I believe a single call to the correct `allocate` method suffices, but in this case I don't think performance should be skewed too much.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363578019
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363578910

From mcimadamore at openjdk.org  Wed Oct 18 09:51:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 09:51:52 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 04:44:26 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop unused in_reg_spiller

Looks very good. I did a pass of all the Java code, tests and benchmarks. And also looked at the fallback linker (both Java and C). I will leave the hotspot parts to others :-)

-------------

PR Review: https://git.openjdk.org/jdk/pull/16201#pullrequestreview-1684611937

From jvernee at openjdk.org  Wed Oct 18 09:51:52 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 09:51:52 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 09:45:25 GMT, Maurizio Cimadamore  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   drop unused in_reg_spiller
>
> test/micro/org/openjdk/bench/java/lang/foreign/CriticalCalls.java line 101:
> 
>> 99:     public int callNotPinned() throws Throwable {
>> 100:         try (Arena arena = Arena.ofConfined()) {
>> 101:             MemorySegment nativeArr = arena.allocate(JAVA_INT, arr.length);
> 
> This allocation method will zero the segment. I think that's a bit unfair and will bias the results against non-pinned, right?

Good point. I made this benchmark a while ago, before we had the more optimized allocate variants

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363582375

From mcimadamore at openjdk.org  Wed Oct 18 10:00:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 10:00:25 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 18 Oct 2023 09:25:49 GMT, Jorn Vernee  wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 795:
>> 
>>> 793:          * memory segments as addresses, where normally only off-heap memory segments would be allowed. The memory region
>>> 794:          * inside the Java heap is exposed through a temporary native address that is valid for the duration of the
>>> 795:          * function call. As such, these temporary addresses, or any addresses derived from them, should not be used
>> 
>> The API does not expose temporary addresses - so it is not 100% clear when reading what this para refers to. I suppose you mean a native function that "captures" an object's address and then returns it, so that the client wraps it in a zero-length memory segment? I can't decide on top of my head if this is too cornery or not, even for this javadoc.
>
> I'm not sure what to write to make this clearer. The address that is exposed to the native target function is indeed a temporary address that is constructed from the oop and offset. It is temporary because after the native call, the GC might move the object around, which invalidates the address.
> 
> This part is meant to document that native code should not be holding on to the address until after the call completes. This also includes returning the address back to Java. The address would be invalid the moment the function returns.
> 
> Would it help if this said: `The memory region inside the Java heap is exposed to the native target function through a temporary native address`?

I'm considering to leave `As such, these temporary addresses...` out. You already said that the address "is valid for the duration of the call". I'm not sure the subsequent sentence adds much. If you want to make a concrete example of something that should not be done, that would be better. But it seems to me that the client is as in charge as this text suggests - (e.g. if a native lib decides to hold onto an address, the client can't do much about it).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363593890

From mcimadamore at openjdk.org  Wed Oct 18 10:00:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 10:00:25 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 18 Oct 2023 09:57:25 GMT, Maurizio Cimadamore  wrote:

>> I'm not sure what to write to make this clearer. The address that is exposed to the native target function is indeed a temporary address that is constructed from the oop and offset. It is temporary because after the native call, the GC might move the object around, which invalidates the address.
>> 
>> This part is meant to document that native code should not be holding on to the address until after the call completes. This also includes returning the address back to Java. The address would be invalid the moment the function returns.
>> 
>> Would it help if this said: `The memory region inside the Java heap is exposed to the native target function through a temporary native address`?
>
> I'm considering to leave `As such, these temporary addresses...` out. You already said that the address "is valid for the duration of the call". I'm not sure the subsequent sentence adds much. If you want to make a concrete example of something that should not be done, that would be better. But it seems to me that the client is as in charge as this text suggests - (e.g. if a native lib decides to hold onto an address, the client can't do much about it).

So, summing up - either we write more and spell what are the things to be on the lookout for, or we leave it out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363595149

From coffeys at openjdk.org  Wed Oct 18 10:09:29 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 18 Oct 2023 10:09:29 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v7]
In-Reply-To: 
References: 
Message-ID: 

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Testcase feedback from Lance

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/cfa65c05..061dad37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=05-06

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From mcimadamore at openjdk.org  Wed Oct 18 10:21:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 10:21:27 GMT
Subject: RFR: 8318363: Foreign benchmarks fail to build on some platforms
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 08:30:37 GMT, Aleksey Shipilev  wrote:

>> Recent regression, see bug. The fix is to use the proper `jlong <-> ptr` converters.
>> 
>> Additional testing:
>>  - [x] Build now passes on ARM32
>>  - [x] Two affected JMH benchmarks still run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jlong.h

Thanks for taking care of this

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16228#pullrequestreview-1684673351

From jvernee at openjdk.org  Wed Oct 18 10:27:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 10:27:28 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Wed, 18 Oct 2023 09:58:12 GMT, Maurizio Cimadamore  wrote:

>> I'm considering to leave `As such, these temporary addresses...` out. You already said that the address "is valid for the duration of the call". I'm not sure the subsequent sentence adds much. If you want to make a concrete example of something that should not be done, that would be better. But it seems to me that the client is as in charge as this text suggests - (e.g. if a native lib decides to hold onto an address, the client can't do much about it).
>
> So, summing up - either we write more and spell what are the things to be on the lookout for, or we leave it out.

Ok, I'll remove the second sentence.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363628571

From abimpoudis at openjdk.org  Wed Oct 18 10:29:32 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 18 Oct 2023 10:29:32 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v7]
In-Reply-To: 
References: 
Message-ID: <8a80EqSdoXu1bOUwloeZHStv8K0gnCScllreKIa4aYQ=.f4e97671-1d40-4eb8-b4d8-9b0c8d98845e@github.com>

> This PR finalizes the feature of unnamed variables and patterns.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove preview lines from a new .out file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/067e358c..bd43790b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649

PR: https://git.openjdk.org/jdk/pull/15649

From lancea at openjdk.org  Wed Oct 18 10:33:40 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Oct 2023 10:33:40 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 10:09:29 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Testcase feedback from Lance

Thank you for the last set up updates Sean

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16115#pullrequestreview-1684700793

From shade at openjdk.org  Wed Oct 18 10:33:47 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 18 Oct 2023 10:33:47 GMT
Subject: RFR: 8318363: Foreign benchmarks fail to build on some platforms
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 08:30:37 GMT, Aleksey Shipilev  wrote:

>> Recent regression, see bug. The fix is to use the proper `jlong <-> ptr` converters.
>> 
>> Additional testing:
>>  - [x] Build now passes on ARM32
>>  - [x] Two affected JMH benchmarks still run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jlong.h

Thanks! I am integrating to unbreak the benchmark builds.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16228#issuecomment-1768154479

From shade at openjdk.org  Wed Oct 18 10:33:48 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 18 Oct 2023 10:33:48 GMT
Subject: Integrated: 8318363: Foreign benchmarks fail to build on some
 platforms
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 21:23:38 GMT, Aleksey Shipilev  wrote:

> Recent regression, see bug. The fix is to use the proper `jlong <-> ptr` converters.
> 
> Additional testing:
>  - [x] Build now passes on ARM32
>  - [x] Two affected JMH benchmarks still run

This pull request has now been integrated.

Changeset: 6fc35142
Author:    Aleksey Shipilev 
URL:       https://git.openjdk.org/jdk/commit/6fc35142315f1616fa35e415005c9483939c6920
Stats:     4 lines in 2 files changed: 2 ins; 0 del; 2 mod

8318363: Foreign benchmarks fail to build on some platforms

Reviewed-by: jvernee, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/16228

From pminborg at openjdk.org  Wed Oct 18 10:37:30 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 10:37:30 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: <9rTQr_Imp_QM07LJkt4ss0eSvEw0JJH9KfB3an1t0K4=.36c4623b-d0a0-404f-a911-32886f6cc532@github.com>

On Wed, 18 Oct 2023 09:22:39 GMT, Per Minborg  wrote:

>> Just curious, do we have any idea how extensively `UnaryOperator` is used as a parameter type in user code compared to plain `Function`? If it's not preferred over `Function`, this new method might not be very useful.
>
> Generally speaking, there are 1,594 usages of `Function` and 208 usages of `UnaryFunction` in the JDK itself. More specifically, there are 8 usages of `Function::andThen` and zero use of `UnaryOperator::andThen` in the JDK.

I've run some corpus analysis and this came up:


pminborg at pminborg-mac open % cat ~/Downloads/experiment-2.log | grep Function.andThen | wc -l
    6689
pminborg at pminborg-mac open % cat ~/Downloads/experiment-2.log | grep UnaryOperator.andThen | wc -l
     153

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16213#discussion_r1363643007

From jvernee at openjdk.org  Wed Oct 18 10:51:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 10:51:22 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 18 Oct 2023 09:48:47 GMT, Jorn Vernee  wrote:

>> test/micro/org/openjdk/bench/java/lang/foreign/CriticalCalls.java line 101:
>> 
>>> 99:     public int callNotPinned() throws Throwable {
>>> 100:         try (Arena arena = Arena.ofConfined()) {
>>> 101:             MemorySegment nativeArr = arena.allocate(JAVA_INT, arr.length);
>> 
>> This allocation method will zero the segment. I think that's a bit unfair and will bias the results against non-pinned, right?
>
> Good point. I made this benchmark a while ago, before we had the more optimized allocate variants

This had a pretty big impact, actually. Especially on the larger sizes:


Benchmark                     (size)  Mode  Cnt       Score       Error  Units
CriticalCalls.callNotPinned      100  avgt   30      84.818 ?     0.729  ns/op
CriticalCalls.callNotPinned    10000  avgt   30    2966.918 ?    39.898  ns/op
CriticalCalls.callNotPinned  1000000  avgt   30  952864.052 ? 34996.156  ns/op
CriticalCalls.callPinned         100  avgt   30      30.640 ?     0.173  ns/op
CriticalCalls.callPinned       10000  avgt   30    2241.403 ?    35.473  ns/op
CriticalCalls.callPinned     1000000  avgt   30  221152.247 ?  1697.968  ns/op
CriticalCalls.callRecycled       100  avgt   30      40.205 ?     0.458  ns/op
CriticalCalls.callRecycled     10000  avgt   30    2845.316 ?    13.331  ns/op
CriticalCalls.callRecycled   1000000  avgt   30  287752.178 ?  2322.382  ns/op

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363661902

From mcimadamore at openjdk.org  Wed Oct 18 11:14:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 11:14:58 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <67T6EClvm9QEAqYr4F4xjgh0mYFwLj0g2Eekx3ecxJA=.8a304336-2d6e-440e-aa55-8f290487f623@github.com>

On Wed, 18 Oct 2023 10:48:58 GMT, Jorn Vernee  wrote:

>> Good point. I made this benchmark a while ago, before we had the more optimized allocate variants
>
> This had a pretty big impact, actually. Especially on the larger sizes:
> 
> 
> Benchmark                     (size)  Mode  Cnt       Score       Error  Units
> CriticalCalls.callNotPinned      100  avgt   30      84.818 ?     0.729  ns/op
> CriticalCalls.callNotPinned    10000  avgt   30    2966.918 ?    39.898  ns/op
> CriticalCalls.callNotPinned  1000000  avgt   30  952864.052 ? 34996.156  ns/op
> CriticalCalls.callPinned         100  avgt   30      30.640 ?     0.173  ns/op
> CriticalCalls.callPinned       10000  avgt   30    2241.403 ?    35.473  ns/op
> CriticalCalls.callPinned     1000000  avgt   30  221152.247 ?  1697.968  ns/op
> CriticalCalls.callRecycled       100  avgt   30      40.205 ?     0.458  ns/op
> CriticalCalls.callRecycled     10000  avgt   30    2845.316 ?    13.331  ns/op
> CriticalCalls.callRecycled   1000000  avgt   30  287752.178 ?  2322.382  ns/op

I also notice that the non pinned variant of the `100` benchmark is slow compared to the others. This might be due to try with resources inhibiting scalarization. I suggest to call Arena::close explicitly in that benchmark and repeat the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363689027

From mdonovan at openjdk.org  Wed Oct 18 11:15:26 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 18 Oct 2023 11:15:26 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  reworked assertThrows and cleaned up the test a bit more

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14932/files
  - new: https://git.openjdk.org/jdk/pull/14932/files/0df1071e..c2610f36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14932&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14932&range=02-03

  Stats: 35 lines in 2 files changed: 6 ins; 15 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14932/head:pull/14932

PR: https://git.openjdk.org/jdk/pull/14932

From jvernee at openjdk.org  Wed Oct 18 11:20:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 11:20:01 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v2]
In-Reply-To: <67T6EClvm9QEAqYr4F4xjgh0mYFwLj0g2Eekx3ecxJA=.8a304336-2d6e-440e-aa55-8f290487f623@github.com>
References: 
 
 
 
 
 <67T6EClvm9QEAqYr4F4xjgh0mYFwLj0g2Eekx3ecxJA=.8a304336-2d6e-440e-aa55-8f290487f623@github.com>
Message-ID: 

On Wed, 18 Oct 2023 11:12:43 GMT, Maurizio Cimadamore  wrote:

>> This had a pretty big impact, actually. Especially on the larger sizes:
>> 
>> 
>> Benchmark                     (size)  Mode  Cnt       Score       Error  Units
>> CriticalCalls.callNotPinned      100  avgt   30      84.818 ?     0.729  ns/op
>> CriticalCalls.callNotPinned    10000  avgt   30    2966.918 ?    39.898  ns/op
>> CriticalCalls.callNotPinned  1000000  avgt   30  952864.052 ? 34996.156  ns/op
>> CriticalCalls.callPinned         100  avgt   30      30.640 ?     0.173  ns/op
>> CriticalCalls.callPinned       10000  avgt   30    2241.403 ?    35.473  ns/op
>> CriticalCalls.callPinned     1000000  avgt   30  221152.247 ?  1697.968  ns/op
>> CriticalCalls.callRecycled       100  avgt   30      40.205 ?     0.458  ns/op
>> CriticalCalls.callRecycled     10000  avgt   30    2845.316 ?    13.331  ns/op
>> CriticalCalls.callRecycled   1000000  avgt   30  287752.178 ?  2322.382  ns/op
>
> I also notice that the non pinned variant of the `100` benchmark is slow compared to the others. This might be due to try with resources inhibiting scalarization. I suggest to call Arena::close explicitly in that benchmark and repeat the test.

Not sure... The `callNotPinned` variant is meant as a typical use case where the native segment needs to be allocated. I think TWR belongs in that typical use-case.

This is really about measuring the difference between 2 idiomatic code patterns. If non-scalarization is part of one of those patterns, then I think that is something that should be included in the measurement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1363694139

From redestad at openjdk.org  Wed Oct 18 12:05:01 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Oct 2023 12:05:01 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: <2FBC5V9-TWvDUJonmS7HYPV2UAVSoDioW0g2rjc46G4=.8dd07697-904e-4c37-8005-d71034809ef9@github.com>

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

I have a relatively strong hypothesis: in the `StringConcatFactory` we bind in `String` constants in the MH expression tree, one for each argument. These constants may be null, which we then branch on, depending on JITs to see that the expression is constant and eliminate the test. Perhaps sometimes the JIT speculates too optimistically (thinking the constant is always null) due to missing profile data and then have to deoptimize and recompile in a more conservative mode where the dead code isn't properly eliminated. 

I have prepared a patch (#16244) which reduces the amount of branches in generated expression trees, which should eliminate some tripwires for the JITs. I'm getting more consistently good scores when running this together with the `"\1.\1\1"` recipe branch:


Benchmark                                 Mode  Cnt   Score   Error  Units
BigDecimals.testSmallToEngineeringString  avgt  100  11,998 ? 0,056  ns/op


Can you test this out in combination with the `"\1.\1\1"` branch and see if the variance improves on your setup too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1768302411

From mcimadamore at openjdk.org  Wed Oct 18 12:10:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 12:10:25 GMT
Subject: RFR: 8318324: Drop redundant default methods from FFM API
Message-ID: 

This PR moves turns default methods in `MemorySegment` and `MemoryLayout` into ordinary abstract methods.
These interfaces cannot be subclasses by developers (they are sealed), so there is no reson for having default methods there. Also, default methods can have some detrimental effects, as they cause the interfaces to be initialized more eagerly.

-------------

Commit messages:
 - Fix whitespaces
 - Drop redundant imports
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/16224/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16224&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318324
  Stats: 628 lines in 4 files changed: 357 ins; 221 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/16224.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16224/head:pull/16224

PR: https://git.openjdk.org/jdk/pull/16224

From jvernee at openjdk.org  Wed Oct 18 12:10:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 12:10:27 GMT
Subject: RFR: 8318324: Drop redundant default methods from FFM API
In-Reply-To: 
References: 
Message-ID: <00NNyFYqQ2BpJbDwhNjU955JeJFY84knGQgUTlTENHY=.d75781a0-9e04-4f5a-a7d1-8743bc910d97@github.com>

On Tue, 17 Oct 2023 17:31:30 GMT, Maurizio Cimadamore  wrote:

> This PR moves turns default methods in `MemorySegment` and `MemoryLayout` into ordinary abstract methods.
> These interfaces cannot be subclasses by developers (they are sealed), so there is no reson for having default methods there. Also, default methods can have some detrimental effects, as they cause the interfaces to be initialized more eagerly.

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/jdk/internal/foreign/layout/AbstractLayout.java line 47:

> 45: import java.util.Optional;
> 46: import java.util.Set;
> 47: import java.util.function.Function;

There are quite a few new imports here. Is it possible some imports in `MemoryLayout` are now unused?

src/java.base/share/classes/jdk/internal/foreign/layout/AbstractLayout.java line 153:

> 151:     }
> 152: 
> 153:     public long scale(long offset, long index) {

Could you add `@Override` to these as well? I think it makes it clearer that these methods might be accessed through a super type.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16224#pullrequestreview-1683950393
PR Review Comment: https://git.openjdk.org/jdk/pull/16224#discussion_r1363143556
PR Review Comment: https://git.openjdk.org/jdk/pull/16224#discussion_r1363143273

From alanb at openjdk.org  Wed Oct 18 12:13:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Oct 2023 12:13:00 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v7]
In-Reply-To: 
References: 
 
Message-ID: <7yb1ZgK4z37uzYJ1rgU3Cb1FWJwHdXpqJjlRwLJwTjs=.e59346da-1052-495f-805e-507d458a71a5@github.com>

On Wed, 18 Oct 2023 10:09:29 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Testcase feedback from Lance

src/java.base/share/classes/java/util/zip/ZipFile.java line 1415:

> 1413:                  * an existing file is updated. The other hash code properties
> 1414:                  * by themselves won't detect such a change.
> 1415:                  */

I see you've added a comment to the checking of the last modified time but I think the comment is a bit confusing as there isn't any detection of a changed zip file in the hashCode/equals methods.  I think you want to say that the lastModifiedTime is included in the hash code to allow for cases where the same file is opened more than once and where it has been modified in the mean-time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1363754433

From mcimadamore at openjdk.org  Wed Oct 18 12:14:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 12:14:04 GMT
Subject: RFR: 8318324: Drop redundant default methods from FFM API
In-Reply-To: <00NNyFYqQ2BpJbDwhNjU955JeJFY84knGQgUTlTENHY=.d75781a0-9e04-4f5a-a7d1-8743bc910d97@github.com>
References: 
 <00NNyFYqQ2BpJbDwhNjU955JeJFY84knGQgUTlTENHY=.d75781a0-9e04-4f5a-a7d1-8743bc910d97@github.com>
Message-ID: 

On Wed, 18 Oct 2023 04:06:17 GMT, Jorn Vernee  wrote:

>> This PR moves turns default methods in `MemorySegment` and `MemoryLayout` into ordinary abstract methods.
>> These interfaces cannot be subclasses by developers (they are sealed), so there is no reson for having default methods there. Also, default methods can have some detrimental effects, as they cause the interfaces to be initialized more eagerly.
>
> src/java.base/share/classes/jdk/internal/foreign/layout/AbstractLayout.java line 47:
> 
>> 45: import java.util.Optional;
>> 46: import java.util.Set;
>> 47: import java.util.function.Function;
> 
> There are quite a few new imports here. Is it possible some imports in `MemoryLayout` are now unused?

No unused import here - these are just the imports required for the overrides to compile successfully.

> src/java.base/share/classes/jdk/internal/foreign/layout/AbstractLayout.java line 153:
> 
>> 151:     }
>> 152: 
>> 153:     public long scale(long offset, long index) {
> 
> Could you add `@Override` to these as well? I think it makes it clearer that these methods might be accessed through a super type.

Would be nice - but note that `AbstractLayoutImpl` does not extend `MemoryLayout`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16224#discussion_r1363753942
PR Review Comment: https://git.openjdk.org/jdk/pull/16224#discussion_r1363755711

From jvernee at openjdk.org  Wed Oct 18 12:19:58 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 12:19:58 GMT
Subject: RFR: 8318324: Drop redundant default methods from FFM API
In-Reply-To: 
References: 
 <00NNyFYqQ2BpJbDwhNjU955JeJFY84knGQgUTlTENHY=.d75781a0-9e04-4f5a-a7d1-8743bc910d97@github.com>
 
Message-ID: 

On Wed, 18 Oct 2023 12:09:28 GMT, Maurizio Cimadamore  wrote:

>> src/java.base/share/classes/jdk/internal/foreign/layout/AbstractLayout.java line 47:
>> 
>>> 45: import java.util.Optional;
>>> 46: import java.util.Set;
>>> 47: import java.util.function.Function;
>> 
>> There are quite a few new imports here. Is it possible some imports in `MemoryLayout` are now unused?
>
> No unused import here - these are just the imports required for the overrides to compile successfully.

I mean in `MemoryLayout` from which these overrides were moved.

>> src/java.base/share/classes/jdk/internal/foreign/layout/AbstractLayout.java line 153:
>> 
>>> 151:     }
>>> 152: 
>>> 153:     public long scale(long offset, long index) {
>> 
>> Could you add `@Override` to these as well? I think it makes it clearer that these methods might be accessed through a super type.
>
> Would be nice - but note that `AbstractLayoutImpl` does not extend `MemoryLayout`.

Ah, right...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16224#discussion_r1363762975
PR Review Comment: https://git.openjdk.org/jdk/pull/16224#discussion_r1363762381

From jvernee at openjdk.org  Wed Oct 18 12:45:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 12:45:05 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v5]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with six additional commits since the last revision:

 - Add xor benchmark
 - add readOnly heap segment test
 - shorten linker doc
 - use allocateFrom in benchmarks
 - use unsafeGetBase in fallback linker
 - remove impl note from isCritical

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/c4a8866b..628d4952

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=03-04

  Stats: 392 lines in 14 files changed: 374 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From jvernee at openjdk.org  Wed Oct 18 12:45:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 12:45:07 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 09:42:27 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Phrasing
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Added another benchmark to the patch that xors 2 arrays together using various strategies. These are the results on my machine:


Benchmark         (arrayKind)  (sizeKind)  Mode  Cnt   Score    Error  Units
XorTest.xor      JNI_ELEMENTS       SMALL  avgt   30   0.555 ?  0.010  ms/op
XorTest.xor      JNI_ELEMENTS      MEDIUM  avgt   30   4.610 ?  0.114  ms/op
XorTest.xor      JNI_ELEMENTS       LARGE  avgt   30  53.533 ?  2.113  ms/op
XorTest.xor        JNI_REGION       SMALL  avgt   30   0.030 ?  0.001  ms/op
XorTest.xor        JNI_REGION      MEDIUM  avgt   30   1.498 ?  0.041  ms/op
XorTest.xor        JNI_REGION       LARGE  avgt   30   7.544 ?  0.188  ms/op
XorTest.xor      JNI_CRITICAL       SMALL  avgt   30   0.035 ?  0.005  ms/op
XorTest.xor      JNI_CRITICAL      MEDIUM  avgt   30   0.496 ?  0.003  ms/op
XorTest.xor      JNI_CRITICAL       LARGE  avgt   30   2.521 ?  0.035  ms/op
XorTest.xor   FOREIGN_NO_INIT       SMALL  avgt   30   0.030 ?  0.001  ms/op
XorTest.xor   FOREIGN_NO_INIT      MEDIUM  avgt   30   1.303 ?  0.021  ms/op
XorTest.xor   FOREIGN_NO_INIT       LARGE  avgt   30   7.668 ?  0.168  ms/op
XorTest.xor      FOREIGN_INIT       SMALL  avgt   30   0.031 ?  0.001  ms/op
XorTest.xor      FOREIGN_INIT      MEDIUM  avgt   30   1.485 ?  0.012  ms/op
XorTest.xor      FOREIGN_INIT       LARGE  avgt   30   9.183 ?  0.247  ms/op
XorTest.xor  FOREIGN_CRITICAL       SMALL  avgt   30   0.026 ?  0.001  ms/op
XorTest.xor  FOREIGN_CRITICAL      MEDIUM  avgt   30   0.501 ?  0.002  ms/op
XorTest.xor  FOREIGN_CRITICAL       LARGE  avgt   30   2.578 ?  0.023  ms/op
XorTest.xor            UNSAFE       SMALL  avgt   30   0.029 ?  0.001  ms/op
XorTest.xor            UNSAFE      MEDIUM  avgt   30   1.300 ?  0.013  ms/op
XorTest.xor            UNSAFE       LARGE  avgt   30   7.632 ?  0.178  ms/op


The important part here is the `FOREIGN_CRITICAL` (the new feature) is on par with `JNI_CRITICAL`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1768370164

From pminborg at openjdk.org  Wed Oct 18 12:53:20 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 12:53:20 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v4]
In-Reply-To: 
References: 
Message-ID: <60TqPCovErwAdi38vpWKqB_JOOvKa_jFL08TbrW04Bc=.e76f226f-2cb9-4ccd-83b1-6605e9f327a8@github.com>

> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
> 
> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
> 
> We need to benchmark this solution to better understand its implications.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge master
 - Merge branch 'master' into vb-map2
 - Remove redundant impl spec parts
 - Merge pull request #4 from cl4es/HashMapViews
   
   Add simple HashMapViews microbenchmark
 - Add simple HashMapViews microbenchmark
 - Remove caching in AbstractMap and make immutable maps @ValueBased

-------------

Changes: https://git.openjdk.org/jdk/pull/15614/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=03
  Stats: 264 lines in 9 files changed: 92 ins; 143 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/15614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15614/head:pull/15614

PR: https://git.openjdk.org/jdk/pull/15614

From jvernee at openjdk.org  Wed Oct 18 13:05:58 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 13:05:58 GMT
Subject: RFR: 8317868: Add @sealedGraph to MethodHandleDesc and descendants
 [v2]
In-Reply-To: 
References: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 11:18:41 GMT, Per Minborg  wrote:

>> This PR proposes to add  @sealedGraph to MethodHandleDesc and descendants.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Revoke change in DMHD

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16137#pullrequestreview-1685020416

From mdoerr at openjdk.org  Wed Oct 18 13:16:00 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Oct 2023 13:16:00 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 12:45:05 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Add xor benchmark
>  - add readOnly heap segment test
>  - shorten linker doc
>  - use allocateFrom in benchmarks
>  - use unsafeGetBase in fallback linker
>  - remove impl note from isCritical

PPC64 code is here:
[PPC64_Panama_heap_segments.patch](https://github.com/openjdk/jdk/files/13025334/PPC64_Panama_heap_segments.patch)
All tests are passing on linux PPC64le. One single test case is failing on Big Endian:
test TestLayoutPaths.testBadAlignmentOfRoot(): failure
java.lang.AssertionError: expected [true] but found [false]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertTrue(Assert.java:45)
	at org.testng.Assert.assertTrue(Assert.java:55)
	at TestLayoutPaths.testBadAlignmentOfRoot(TestLayoutPaths.java:157)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1570)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1768430267

From rriggs at openjdk.org  Wed Oct 18 13:48:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Oct 2023 13:48:57 GMT
Subject: RFR: JDK-8318415: Adjust describing comment of os_getChildren
 after 8315026
In-Reply-To: <8pQJPDwoYZ69TAln8NHL8WnuD8Ts0dkR9jC5jxrZL7o=.1c6793df-94f5-4c37-8e7a-ea47e8408cdd@github.com>
References: <8pQJPDwoYZ69TAln8NHL8WnuD8Ts0dkR9jC5jxrZL7o=.1c6793df-94f5-4c37-8e7a-ea47e8408cdd@github.com>
Message-ID: 

On Wed, 18 Oct 2023 08:18:47 GMT, Matthias Baesken  wrote:

> 8315026 adjusted and improved the describings comments already for AIX/Linux. But macOS was not adjusted.

Thanks for the updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16236#pullrequestreview-1685133266

From jvernee at openjdk.org  Wed Oct 18 13:52:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 13:52:01 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 13:13:07 GMT, Martin Doerr  wrote:

> Note: This error is not related to this PR. It was broken by https://github.com/openjdk/jdk/commit/b12c471a990eb8f789410a20084918368c655659 which is incorrect for Big Endian. Should I file a new issue or is that already known?

Please file a new issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1768504257

From mcimadamore at openjdk.org  Wed Oct 18 13:53:35 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 13:53:35 GMT
Subject: RFR: 8318324: Drop redundant default methods from FFM API [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR moves turns default methods in `MemorySegment` and `MemoryLayout` into ordinary abstract methods.
> These interfaces cannot be subclasses by developers (they are sealed), so there is no reson for having default methods there. Also, default methods can have some detrimental effects, as they cause the interfaces to be initialized more eagerly.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16224/files
  - new: https://git.openjdk.org/jdk/pull/16224/files/66123ead..9c3fe1d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16224&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16224&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16224.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16224/head:pull/16224

PR: https://git.openjdk.org/jdk/pull/16224

From abimpoudis at openjdk.org  Wed Oct 18 13:55:28 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 18 Oct 2023 13:55:28 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v24]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <8MeIwxrLkHfHK2L1Apr_86j9aA6M1vgt9tTE5UrX8gQ=.3cf317f0-dee5-4691-91e7-368ab7cee2f5@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix SwitchBootstraps for pattern matching over longs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/4acb66e0..248971be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=22-23

  Stats: 27 lines in 2 files changed: 26 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From jvernee at openjdk.org  Wed Oct 18 14:12:58 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 14:12:58 GMT
Subject: RFR: 8318324: Drop redundant default methods from FFM API [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 13:53:35 GMT, Maurizio Cimadamore  wrote:

>> This PR moves turns default methods in `MemorySegment` and `MemoryLayout` into ordinary abstract methods.
>> These interfaces cannot be subclasses by developers (they are sealed), so there is no reson for having default methods there. Also, default methods can have some detrimental effects, as they cause the interfaces to be initialized more eagerly.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16224#pullrequestreview-1685198777

From jvernee at openjdk.org  Wed Oct 18 14:29:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 14:29:01 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v6]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - add PPC impl
 - add missing file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/628d4952..07d06216

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=04-05

  Stats: 156 lines in 3 files changed: 81 ins; 62 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From jvernee at openjdk.org  Wed Oct 18 14:29:04 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 14:29:04 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 13:13:07 GMT, Martin Doerr  wrote:

>> Jorn Vernee has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Add xor benchmark
>>  - add readOnly heap segment test
>>  - shorten linker doc
>>  - use allocateFrom in benchmarks
>>  - use unsafeGetBase in fallback linker
>>  - remove impl note from isCritical
>
> PPC64 code is here:
> [PPC64_Panama_heap_segments.patch](https://github.com/openjdk/jdk/files/13025334/PPC64_Panama_heap_segments.patch)
> All tests are passing on linux PPC64le. One single test case is failing on Big Endian:
> test TestLayoutPaths.testBadAlignmentOfRoot(): failure
> java.lang.AssertionError: expected [true] but found [false]
> 	at org.testng.Assert.fail(Assert.java:99)
> 	at org.testng.Assert.failNotEquals(Assert.java:1037)
> 	at org.testng.Assert.assertTrue(Assert.java:45)
> 	at org.testng.Assert.assertTrue(Assert.java:55)
> 	at TestLayoutPaths.testBadAlignmentOfRoot(TestLayoutPaths.java:157)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
> 	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
> 	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
> 	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
> 	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
> 	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
> 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:764)
> 	at org.testng.TestRunner.run(TestRunner.java:585)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> 	at org.testng.TestNG.runSuites(TestNG.java:1069)
> 	at org.testng.TestNG.run(TestNG.java:1037)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> ...

@TheRealMDoerr Thanks for the patch, I've added it to the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1768582362

From duke at openjdk.org  Wed Oct 18 14:40:02 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 18 Oct 2023 14:40:02 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

After adding patch #16244, I ran it many times without the occasional slowdown.  

adding patch branch : https://github.com/wenshao/jdk/tree/optim_decimal_to_string_x1_mcwc_3 

Can we go one step further and add some prepend methods for char type prefix? Like this:


public final class StringConcatFactory {
    private static MethodHandle prepender(String prefix, Class cl) {
        if (prefix == null || prefix.isEmpty()) {
            return noConstantPrepender(cl);
        } else {
            if (prefix.length() == 1
                    && (cl == boolean.class
                    || cl == char.class
                    || cl == int.class
                    || cl == long.class
                    || cl == String.class)
            ) {
                char ch = prefix.charAt(0);
                MethodHandle prepend = JLA.stringConcatHelper(
                        "prepend",
                        methodType(long.class, long.class, byte[].class, cl, char.class)).rebind();
                return MethodHandles.insertArguments(prepend, 3, ch);
            }
            return MethodHandles.insertArguments(
                    prepender(cl), 3, prefix);
        }
    }
}

class StringConcatHelper {
    private static long prepend(long indexCoder, byte[] buf, char value, char prefix) {
        if (indexCoder < UTF16) {
            buf[(int)(--indexCoder)] = (byte) (value & 0xFF);
            buf[(int)(--indexCoder)] = (byte) (prefix & 0xFF);
        } else {
            StringUTF16.putChar(buf, (int)(--indexCoder), value);
            StringUTF16.putChar(buf, (int)(--indexCoder), prefix);
        }
        return indexCoder;
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1768608568

From mdoerr at openjdk.org  Wed Oct 18 14:41:01 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Oct 2023 14:41:01 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 13:13:07 GMT, Martin Doerr  wrote:

>> Jorn Vernee has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Add xor benchmark
>>  - add readOnly heap segment test
>>  - shorten linker doc
>>  - use allocateFrom in benchmarks
>>  - use unsafeGetBase in fallback linker
>>  - remove impl note from isCritical
>
> PPC64 code is here:
> [PPC64_Panama_heap_segments.patch](https://github.com/openjdk/jdk/files/13025334/PPC64_Panama_heap_segments.patch)
> All tests are passing on linux PPC64le. One single test case is failing on Big Endian:
> test TestLayoutPaths.testBadAlignmentOfRoot(): failure
> java.lang.AssertionError: expected [true] but found [false]
> 	at org.testng.Assert.fail(Assert.java:99)
> 	at org.testng.Assert.failNotEquals(Assert.java:1037)
> 	at org.testng.Assert.assertTrue(Assert.java:45)
> 	at org.testng.Assert.assertTrue(Assert.java:55)
> 	at TestLayoutPaths.testBadAlignmentOfRoot(TestLayoutPaths.java:157)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
> 	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
> 	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
> 	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
> 	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
> 	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
> 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:764)
> 	at org.testng.TestRunner.run(TestRunner.java:585)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> 	at org.testng.TestNG.runSuites(TestNG.java:1069)
> 	at org.testng.TestNG.run(TestNG.java:1037)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> ...

> @TheRealMDoerr Thanks for the patch, I've added it to the PR.

Thanks for adding it!

I wonder if the native_invoker_size_per_arg thing still works good enough. We may exceed the computed size, now, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1768610367

From mdoerr at openjdk.org  Wed Oct 18 14:47:59 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Oct 2023 14:47:59 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: <5f9gy8HbHFVJAgWJ1XIUsxwSwFhyRD9s2z092DlNKpQ=.6de10af8-51b0-4802-84a8-88d37048e07b@github.com>

On Wed, 18 Oct 2023 13:49:40 GMT, Jorn Vernee  wrote:

> > Note: This error is not related to this PR. It was broken by https://github.com/openjdk/jdk/commit/b12c471a990eb8f789410a20084918368c655659 which is incorrect for Big Endian. Should I file a new issue or is that already known?
> 
> Please file a new issue.

Filed https://bugs.openjdk.org/browse/JDK-8318454.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1768623075

From jvernee at openjdk.org  Wed Oct 18 14:51:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 14:51:01 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 18 Oct 2023 14:38:41 GMT, Martin Doerr  wrote:

> I wonder if the native_invoker_size_per_arg thing still works good enough. We may exceed the computed size, now, right?

Good point. I'll have a look at enhancing the test we have for this. 

Intuitively, I think it will be okay. It's true that we generate more code to add the oops and offsets together, but at the same time, we don't have any code to shuffle the offsets.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1768630249

From ramadasu.nandagiri at hpe.com  Wed Oct 18 14:55:04 2023
From: ramadasu.nandagiri at hpe.com (Nandagiri, Ramadasu (NSDi))
Date: Wed, 18 Oct 2023 14:55:04 +0000
Subject: Request for JCK17 tests exclusion
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
Message-ID: 

Hi,

Please see the discussion in the following mails. One of the TCK test cases, api/java_net/MulticastSocket/ClassLevel.html is failing on NonStop platform as NonStop doesn't support IP_MULTICAST_ALL option.

We would like this test case to be excluded from TCK. Please share your thoughts on this request.

Regards,
Ramdas
________________________________
From: conformance-octla-private  on behalf of Dmitry Bessonov 
Sent: Saturday, October 14, 2023 3:23 PM
To: Bhat, Suma Mudakare Bheema (NSDi) 
Cc: conformance-octla-private at openjdk.java.net 
Subject: Re: Request for JCK17 tests exclusion

Hi Suma,

Thank you for providing more details. They seem to be reflecting NonStop implementation specifics and issues, which may not be convincing reason to exclude a JCK test.

The test looks conforming to the specification and passes on the JavaSE 17 Reference Implementation. If you believe the test is incorrect we would appreciate to know where the test is making incorrect assumption or doesn't follow the specification.

If you think that there might be a problem with JavaSE 17 specification or the implementation per spec is not possible on your platform, the place for related communication could be net-dev at openjdk.org or core-libs-dev at openjdk.org.

Kind regards,
JCK Team


> On 13 Oct 2023, at 14:30, Bhat, Suma Mudakare Bheema (NSDi)  wrote:
>
> Thanks Krushna for your response.
>
> Thanks for excluding the testcase api/java_net/MulticastSocket/SupportedOptionsTest.html.
>
> Please find additional details from our side regarding the testcase api/java_net/MulticastSocket/ClassLevel.html.
>
> Snippet from your mail:
> Behavior on NonStop platform, when socket relinquishes membership from a group is still getting the datagrams sent to that group.
> Suspecting there could be some issue with the port configuration w.r.to multicast handling.
>
> Our response:  We compared NonStop Java code for socket creation with Linux specific Java code. On Linux, testcase passes because it supports IP_MULTICAST_ALL option as given below(See: code snippet). It disables IP_MULTICAST_ALL for the socket created on Linux. We have compared C and Java testcase behavior on Linux. We have observed that IP_MULTICAST_ALL makes the difference.  NonStop CIP stack (aka TCP/IP stack)  doesn't have the behavior of enabling/disabling of IP_MULTICAST_ALL option as it is not supported. Hence, the testcase fails on the NonStop platform. So, we are requesting for the exclusion of the testcase.
>
> #if defined(__linux__)
>    if (type == SOCK_DGRAM) {
>        int arg = 0;
>        int level = (domain == AF_INET6) ? IPPROTO_IPV6 : IPPROTO_IP;
>        if ((setsockopt(fd, level, IP_MULTICAST_ALL, (char*)&arg, sizeof(arg)) < 0) &&
>            (errno != ENOPROTOOPT)) {
>            JNU_ThrowByNameWithLastError(env,
>                                         JNU_JAVANETPKG "SocketException",
>                                         "Unable to set IP_MULTICAST_ALL");
>            close(fd);
>            return -1;
>        }
>    }
> ..
> ..
> #endif
>
> As per the manual for IPv4 implementation on Linux:
> IP_MULTICAST_ALL (since Linux 2.6.31)
>              This option can be used to modify the delivery policy of
>              multicast messages.  The argument is a boolean integer
>              (defaults to 1).  If set to 1, the socket will receive
>              messages from all the groups that have been joined
>              globally on the whole system.  Otherwise, it will deliver
>              messages only from the groups that have been explicitly
>              joined (for example via the IP_ADD_MEMBERSHIP option) on
>              this particular socket.
>
> Please let us know if you need any other information on the same.
> Thanks and regards,
> Suma
>
> -----Original Message-----
> From: Krushnareddy Ganapureddy 
> Sent: Thursday, October 12, 2023 4:04 PM
> To: Bhat, Suma Mudakare Bheema (NSDi) ; conformance-octla-private at openjdk.java.net
> Cc: Nandagiri, Ramadasu (NSDi) ; Gragg, Jeffrey 
> Subject: RE: Request for JCK17 tests exclusion
>
> Hi Suma,
>
> - api/java_net/MulticastSocket/ClassLevel.html
>
> The test expectations as per Java SE conformance specification: (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/MulticastSocket.html ) "When a socket subscribes to a multicast group/port, it receives datagrams sent by other hosts to the group/port, as do all other members of the group and port. A socket relinquishes membership in a group by the leaveGroup(SocketAddress mcastaddr, NetworkInterface netIf) method. "
>
> Behavior on NonStop platform, when socket relinquishes membership from a group is still getting the datagrams sent to that group.
> Suspecting there could be some issue with the port configuration w.r.to multicast handling.
>
> - api/java_net/MulticastSocket/SupportedOptionsTest.html ,  we would be excluding this.
>
> Thanks & regards,
> Krushna.
>
>
> -----Original Message-----
> From: conformance-octla-private  On Behalf Of Bhat, Suma Mudakare Bheema (NSDi)
> Sent: Monday, October 9, 2023 3:20 PM
> To: conformance-octla-private at openjdk.java.net; Dmitry Bessonov 
> Cc: Nandagiri, Ramadasu (NSDi) ; Gragg, Jeffrey 
> Subject: RE: Request for JCK17 tests exclusion
>
> Hi Dmitry,
> Thanks for your inputs. Please find updated tests exclusion request for two tests as below.
>
> Test Challenger Name and Company: Hewlett Packard Enterprise Specification Name(s) and Version(s): Java Platform SE 17 API Specifications Test Suite Name and Version: JCK-runtime-17 Exclude List Version: jck-17-upd-exc-23_jun_2023 Tests Name: api/java_net/MulticastSocket/ClassLevel.html
>                                           api/java_net/MulticastSocket/SupportedOptionsTest.html
>
> Complaint (argument for why test is invalid):
> For testcase : api/java_net/MulticastSocket/ClassLevel.html:
> We are challenging this test case based on " Test assumes unreasonable hardware or software requirements".
> Our platform HPE NonStop doesn't support IP_MULTICAST_ALL, and also there is no equivalent option.
> For the testcase (api/java_net/MulticastSocket/SupportedOptionsTest.html), it needs support for Multicast Socket (IP_MULTICAST_ALL) in the native platform to pass. With the lack of support for multicast support in the native platform, this testcase fails on NonStop.
> I have attached .jtr file for this issue (ClassLevel.jtr)
>
> For testcase: api/java_net/MulticastSocket/SupportedOptionsTest.html:
> We are challenging this test case based on "Test assumes unreasonable hardware or software requirements".
> Our platform HPE NonStop doesn't support IP_MULTICAST_IF on a loop back interface.
> This testcase tries to set IP_MULTICAST_IF on a loop back interface. This is not supported on NonStop platform.
> Hence, this testcase fails. We think, either check for this support should be verified by calling the API  (supportsMulticast()) before setting IP_MULTICAST_IF option in the testcase, Or this testcase should be excluded.
> I have attached .jtr file for this issue (SupportedOptionsTest.jtr)
>
> There is no specific mention about these socket options in our networking manual. Hence, I have attached the mail communication with our networking team regarding the non-supportability of these options on NonStop.
>
> Thanks and Regards,
> Suma
>
>
> -----Original Message-----
> From: Dmitry Bessonov 
> Sent: Tuesday, October 3, 2023 2:12 AM
> To: Bhat, Suma Mudakare Bheema (NSDi) 
> Cc: conformance-octla-private at openjdk.java.net
> Subject: Re: Request for TCK17 tests exclusion
>
> Hi Suma,
>
> We would much appreciate to have more information regarding specifically which exact part of the normative JavaSE 17 specification the tests contradict.
>
> This would help to process the challenge following JCK17 User?s Guide, Chapter 2.3 "JCK Test Appeals Process?. It would allow to confirm each test?s validity or invalidity which are determined basing on technical correctness - see 2.3 for the possible list of justifications. Please note that the same Chapter 2.3 also mentions that "challenges based upon issues unrelated to technical correctness as defined by the specification will normally be rejected.?
>
> Thank you in advance,
>
> Best Regards,
> JCK Team
>
>> On 28 Sep 2023, at 13:55, Bhat, Suma Mudakare Bheema (NSDi)  wrote:
>>
>> Hi,
>> Test Challenger Name and Company: Hewlett Packard Enterprise
>> Specification Name(s) and Version(s): Java Platform SE 17 API
>> Specifications Test Suite Name and Version: JCK-runtime-17 Exclude
>> List Version: jck-17-upd-exc-23_jun_2023 Tests Name:
>> api/java_net/MulticastSocket/ClassLevel.html
>>
>> api/java_net/MulticastSocket/SupportedOptionsTest.html
>> Complaint (argument for why test is invalid):
>> api/java_net/MulticastSocket/ClassLevel.html:
>> For this testcase, it needs support for Multicast Socket (IP_MULTICAST_ALL)  to modify the delivery policy of multicast messages, in the native platform.
>> Our platform NonStop doesn?t have IP_MULTICAST_ALL  support.
>> With the lack of support for multicast support, this testcase fails.
>> I have attached .jtr file for this issue (ClassLevel.jtr)
>> api/java_net/MulticastSocket/SupportedOptionsTest.html:
>> This testcase tries to set IP_MULTICAST_IF on a loop back interface. This is not supported on NonStop platform.
>> Hence, this testcase fails. We think, either check for this support
>> should be verified by calling the API  (supportsMulticast()) before setting IP_MULTICAST_IF option, Or this testcase should be excluded.
>> I have attached .jtr file for this issue (SupportedOptionsTest.jtr)
>> Thanks and Regards, Suma
>>
>> ____________________________
>> ___________________ conformance-octla-private mailing list
>> conformance-octla-private at openjdk.org
>> INVALID URI REMOVED
>> conformance-octla-private__;!!NpxR!jgSANkxAYFdYELEXkxw4jk5YRV4TCNjtfsB
>> r3RNqovQ_kJm-0GhnL11uJ1NWAqPLjae2NMkD_NlG-m3Yg49hnNZf2rY$
>
>
> _______________________________________________
> conformance-octla-private mailing list
> conformance-octla-private at openjdk.org
> https://mail.openjdk.org/mailman/listinfo/conformance-octla-private

_______________________________________________
conformance-octla-private mailing list
conformance-octla-private at openjdk.org
https://mail.openjdk.org/mailman/listinfo/conformance-octla-private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From redestad at openjdk.org  Wed Oct 18 14:55:06 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Oct 2023 14:55:06 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

Maybe, maybe not: it would require a bit of additional code (one method per class; a new cache for performant bootstrapping), and might cause a surprising increase in classes generated during startup/warmup so we need to look carefully at that.

Either way that's out of scope for this PR. Altering `StringConcatFactory` as per #16244 is a reasonable initial follow-up here, with no or only very limited downsides AFAICT.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1768639320

From rriggs at openjdk.org  Wed Oct 18 14:58:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Oct 2023 14:58:04 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed
 [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 15 Oct 2023 16:36:33 GMT, Mahendra Chhipa  wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected use of whitespace in text block.

Please re-generate the files for each old revisions using the new template (and compare).
The "mechanically generated" notation is not in the versions in the PR.

test/jdk/javax/xml/jaxp/datatype/8033980/GregorianCalAndDurSerDataUtil.java line 127:

> 125:         HexFormat hex = HexFormat.of().withPrefix(" (byte) 0x").withSuffix(",");
> 126:         for (int i = 0; i < bytes.length; i += linelen) {
> 127:             sb.append("\n");

Add some indentation before each line so the resulting code is properly indented.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13537#issuecomment-1768642461
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1364030623

From ihse at openjdk.org  Wed Oct 18 15:16:00 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 18 Oct 2023 15:16:00 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

make/modules/jdk.localedata/Gensrc.gmk line 39:

> 37: GENSRC_DIR := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata
> 38: CLDR_GEN_DONE := $(GENSRC_DIR)/_cldr-gensrc.marker
> 39: TZ_DATA_DIR := $(MODULE_SRC)/../java.base/share/data/tzdata

This seems like a bit of abuse of `$(MODULE_SRC)`. I thought we had a macro to get the proper source path for another module, but if we do, I cannot find it now.

If you feel up for it, I'd encourage you to change this to:

Suggestion:

TZ_DATA_DIR := $(call FindModuleSrc, java.base)/share/data/tzdata


and add 

################################################################################
# Find source dir for module
# Param 1 - module name
FindModuleSrc = \
    $(TOPDIR)/src/$(strip $1)

at a suitable place in `Utils.gmk`.

Otherwise, just replace it with:


TZ_DATA_DIR :=  $(TOPDIR)/src/java.base/share/data/tzdata

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16206#discussion_r1364065717

From pminborg at openjdk.org  Wed Oct 18 15:18:14 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 15:18:14 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
> 
> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
> 
> We need to benchmark this solution to better understand its implications.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove AbstractMap::clone

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15614/files
  - new: https://git.openjdk.org/jdk/pull/15614/files/3e7821bf..9b25827a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=03-04

  Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15614/head:pull/15614

PR: https://git.openjdk.org/jdk/pull/15614

From pminborg at openjdk.org  Wed Oct 18 15:18:18 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 15:18:18 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v3]
In-Reply-To: <3bDFFHdMJo1fITcmFynsbMoC9fsyJ8wpFp5_Ww1Zn7k=.e2113679-680b-401e-b625-ae47de4c711a@github.com>
References: 
 <8Y_HVJGTPU6vuu1YlwLrHJvAzNCTekesg6eSmGZu3QI=.5ff02864-ec82-4c2a-a21a-13d987852ff9@github.com>
 
 <3bDFFHdMJo1fITcmFynsbMoC9fsyJ8wpFp5_Ww1Zn7k=.e2113679-680b-401e-b625-ae47de4c711a@github.com>
Message-ID: 

On Fri, 22 Sep 2023 15:31:13 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/util/AbstractMap.java line 524:
>> 
>>> 522:     protected Object clone() throws CloneNotSupportedException {
>>> 523:         AbstractMap result = (AbstractMap)super.clone();
>>> 524:         return result;
>> 
>> Suggestion:
>> 
>>         return super.clone();
>
> Since this base class has no more fields, this method should probably be removed and its spec change included as part of the CSR.

The method has been removed and the spec change has been incorporated into the CSR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1364068379

From pminborg at openjdk.org  Wed Oct 18 15:18:15 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 15:18:15 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v5]
In-Reply-To: 
References: 
 <8fOcDAP-yNMbgd_SLIAlrYCmKwGQWvo2NeJX3CnW8n8=.753376b5-1bf1-4e25-8459-4bf138ad8b1e@github.com>
 
Message-ID: 

On Tue, 19 Sep 2023 23:48:07 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/util/AbstractMap.java line 375:
>> 
>>> 373:      */
>>> 374:     public Collection values() {
>>> 375:         return new AbstractCollection<>() {
>> 
>> Note?that this?causes `m.values().equals(m.values())` to?no?longer return?`true`, as?base `Collection::equals` is?defined using?reference?equality.
>
> Looking at the specification above: 
>> No synchronization is performed, so there is a slight chance that multiple calls to this method will not all return the same collection.
> 
> This should be an acceptable change to behavior.

This is brought to attention in the CSR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1364066788

From lancea at openjdk.org  Wed Oct 18 15:20:59 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Oct 2023 15:20:59 GMT
Subject: RFR: 8318322: Update IANA Language Subtag Registry to Version
 2023-10-16
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu  wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16227#pullrequestreview-1685391866

From Alan.Bateman at oracle.com  Wed Oct 18 15:21:41 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Oct 2023 16:21:41 +0100
Subject: Request for JCK17 tests exclusion
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
Message-ID: 

On 18/10/2023 15:55, Nandagiri, Ramadasu (NSDi) wrote:
> Hi,
>
> Please see the discussion in the following mails. One of the TCK test 
> cases, api/java_net/MulticastSocket/ClassLevel.html is failing on 
> NonStop platform as NonStop doesn't support?IP_MULTICAST_ALL option.
>
> We would like this test case to be excluded from TCK. Please share 
> your thoughts on this request.

I realize you have been directed here but this is not the right place to 
discuss TCK exclusion requests.

 From the mails you forwarded then it looks like there are issues with 
the multicast support in your port to NonStop. The IP_MULTICAST_ALL 
socket option you mention is used in the Linux port to avoid 
interference when two sockets are bound to the same port but joined to 
different multicast groups. Linux is an outlier in this scenario so the 
socket option is set to prevent the interference. My guess is that few 
people here will know NonStop but you could being porting questions on 
this code to net-dev.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pminborg at openjdk.org  Wed Oct 18 15:24:14 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 15:24:14 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v6]
In-Reply-To: 
References: 
Message-ID: 

> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
> 
> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
> 
> We need to benchmark this solution to better understand its implications.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add 'fresh' to implSpec

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15614/files
  - new: https://git.openjdk.org/jdk/pull/15614/files/9b25827a..fabdb59b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15614/head:pull/15614

PR: https://git.openjdk.org/jdk/pull/15614

From coffeys at openjdk.org  Wed Oct 18 15:36:01 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 18 Oct 2023 15:36:01 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v7]
In-Reply-To: <5i8oE7FeOG7W7B2C5jqyKuGNJ_EHf9POIox606GDhzs=.faa3ffd1-6fa6-4a40-984b-a6557e685c0e@github.com>
References: 
 <5i8oE7FeOG7W7B2C5jqyKuGNJ_EHf9POIox606GDhzs=.faa3ffd1-6fa6-4a40-984b-a6557e685c0e@github.com>
Message-ID: <_Vgd0WYiSEwGjpIiBRdafJEZGZSsKoeSGpZ5g0Kn_5o=.8e185a33-025b-49b0-b624-c92ca1ddc0f4@github.com>

On Mon, 18 Sep 2023 13:17:25 GMT, Lance Andersen  wrote:

>> Please review this PR which improves the Zip64 extra header validation:
>> 
>> - Throw a ZipException If the extra len field is 0 and :
>> -- size, csize, or loc offset are set to 0xFFFFFFFF
>> -- disk starting number is set to 0xFFFF
>> 
>> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
>> 
>> Mach5 tiers 1-3 are clean
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing space

Looks good to me Lance. I note that the extra checks aren't reversed via any sort of system property but given that this fix isn't planned for JDK update releases, that seems fine to me.

early testing by frameworks which create/modify custom zip files will be important.

-------------

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15650#pullrequestreview-1685425990

From mcimadamore at openjdk.org  Wed Oct 18 15:38:14 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 15:38:14 GMT
Subject: RFR: 8318458: Update javac and java manpages with restricted method
 options
Message-ID: 

This PR updates the man pages for `javac` and `java` to document:
* the new `javac` warning for restricted methods (`-Xlint:restricted`)
* the `java` option to allow access to restricted methods without warnings (`--enable-native-access`)

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/16249/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16249&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318458
  Stats: 21 lines in 2 files changed: 17 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16249.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16249/head:pull/16249

PR: https://git.openjdk.org/jdk/pull/16249

From naoto at openjdk.org  Wed Oct 18 15:43:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Oct 2023 15:43:12 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v4]
In-Reply-To: 
References: 
Message-ID: 

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fix makefile for the tz data path

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16206/files
  - new: https://git.openjdk.org/jdk/pull/16206/files/4559203d..3d6f695d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16206&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16206&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16206.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16206/head:pull/16206

PR: https://git.openjdk.org/jdk/pull/16206

From naoto at openjdk.org  Wed Oct 18 15:43:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Oct 2023 15:43:14 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 15:13:14 GMT, Magnus Ihse Bursie  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Delay populating GMT format at runtime. Reflecting review comments.
>
> make/modules/jdk.localedata/Gensrc.gmk line 39:
> 
>> 37: GENSRC_DIR := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata
>> 38: CLDR_GEN_DONE := $(GENSRC_DIR)/_cldr-gensrc.marker
>> 39: TZ_DATA_DIR := $(MODULE_SRC)/../java.base/share/data/tzdata
> 
> This seems like a bit of abuse of `$(MODULE_SRC)`. I thought we had a macro to get the proper source path for another module, but if we do, I cannot find it now.
> 
> If you feel up for it, I'd encourage you to change this to:
> 
> Suggestion:
> 
> TZ_DATA_DIR := $(call FindModuleSrc, java.base)/share/data/tzdata
> 
> 
> and add 
> 
> ################################################################################
> # Find source dir for module
> # Param 1 - module name
> FindModuleSrc = \
>     $(TOPDIR)/src/$(strip $1)
> 
> at a suitable place in `Utils.gmk`.
> 
> Otherwise, just replace it with:
> 
> 
> TZ_DATA_DIR :=  $(TOPDIR)/src/java.base/share/data/tzdata

Thanks, Magnus. In fact, I was wondering if I should move back tzdata into make as it is shared like cldr, but it would revert the work you did before, so I ended up traversing the directory structure. Fixed with the latter suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16206#discussion_r1364102062

From redestad at openjdk.org  Wed Oct 18 15:51:24 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Oct 2023 15:51:24 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions
Message-ID: 

In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.

-------------

Commit messages:
 - Naming consistency: noPrefixPrepender
 - FormatItem should call prepend(long, byte[], String)
 - Merge branch 'master' into scf_less_branches
 - Rename NULL to NO_PREFIX to better describe what these are for
 - Only generate prepend with prefix on non-null constants to avoid branch misses and JIT speculation issues

Changes: https://git.openjdk.org/jdk/pull/16244/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16244&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318457
  Stats: 36 lines in 3 files changed: 14 ins; 9 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16244/head:pull/16244

PR: https://git.openjdk.org/jdk/pull/16244

From mcimadamore at openjdk.org  Wed Oct 18 15:57:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 15:57:03 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v6]
In-Reply-To: 
References: 
 
Message-ID: <1IPTFSCCyviLmU7-l-tE8lhKfHxNoHUCgAslQimIA6k=.05271756-fb05-42e5-b029-120ccd4d426b@github.com>

On Wed, 18 Oct 2023 14:29:01 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add PPC impl
>  - add missing file

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16201#pullrequestreview-1685475694

From coffeys at openjdk.org  Wed Oct 18 15:59:13 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 18 Oct 2023 15:59:13 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v8]
In-Reply-To: 
References: 
Message-ID: 

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Update lastModifiedTime comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/061dad37..d126c7f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=06-07

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From srl at openjdk.org  Wed Oct 18 16:01:02 2023
From: srl at openjdk.org (Steven Loomis)
Date: Wed, 18 Oct 2023 16:01:02 GMT
Subject: RFR: 8318322: Update IANA Language Subtag Registry to Version
 2023-10-16
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu  wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

Marked as reviewed by srl (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16227#pullrequestreview-1685483927

From redestad at openjdk.org  Wed Oct 18 16:02:04 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Oct 2023 16:02:04 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
Message-ID: 

On Mon, 16 Oct 2023 15:00:42 GMT, Shaojin Wen  wrote:

>> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
>> 
>> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
>> Please review and don't hesitate to critique my approach and patch.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use StringConcatFactory.makeConcatWithConstants

I've opened up #16244 for review - thanks for helping with analysis and verification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1768806185

From jlaskey at openjdk.org  Wed Oct 18 16:06:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 18 Oct 2023 16:06:58 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 Oct 2023 11:56:14 GMT, Claes Redestad  wrote:

> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16244#pullrequestreview-1685497018

From mgronlun at openjdk.org  Wed Oct 18 16:08:58 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 18 Oct 2023 16:08:58 GMT
Subject: RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 16 Oct 2023 11:28:36 GMT, Erik Gahlin  wrote:

>> Hi,
>> 
>> Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base.
>> 
>> To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. 
>> 
>> Testing: tier1-3 + jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Blessed order

Marked as reviewed by mgronlun (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16195#pullrequestreview-1685500562

From lancea at openjdk.org  Wed Oct 18 16:16:01 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Oct 2023 16:16:01 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v8]
In-Reply-To: 
References: 
 
Message-ID: <_Ms2EZiNeNxh99a5fYBfQvbJTO-zyLuPSCOhqvE42xQ=.c9efcb2f-0055-4845-b2de-9069340ec0cb@github.com>

On Wed, 18 Oct 2023 15:59:13 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update lastModifiedTime comment

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16115#pullrequestreview-1685516723

From redestad at openjdk.org  Wed Oct 18 16:17:54 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 18 Oct 2023 16:17:54 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions
In-Reply-To: 
References: 
 
Message-ID: <5sBunBy4PTE_i-ajqa6Ii4sEuxS0wFFSqdO0U5jvDSc=.4aa56ef8-b45c-49e2-88b4-74e1dc4c286f@github.com>

On Wed, 18 Oct 2023 16:04:34 GMT, Jim Laskey  wrote:

>> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.
>
> Marked as reviewed by jlaskey (Reviewer).

Thanks for the quick review, @JimLaskey! I'll await tier1-3 test results before integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16244#issuecomment-1768877287

From iris at openjdk.org  Wed Oct 18 16:23:59 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Oct 2023 16:23:59 GMT
Subject: RFR: 8318458: Update javac and java manpages with restricted
 method options
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 Oct 2023 15:32:34 GMT, Maurizio Cimadamore  wrote:

> This PR updates the man pages for `javac` and `java` to document:
> * the new `javac` warning for restricted methods (`-Xlint:restricted`)
> * the `java` option to allow access to restricted methods without warnings (`--enable-native-access`)

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16249#pullrequestreview-1685540336

From rriggs at openjdk.org  Wed Oct 18 16:30:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Oct 2023 16:30:59 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen  wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

The new usages that are driving this change would be better served by a method dedicated to creating latin1 strings from a caller provided byte array.  The JavaLangAccess shared secret interface is already overused, but it is cleaner, more maintainable, and fit for purpose to add a method than to contort the exception handling as proposed.  


     /**
       * Return a String constructed using the byte array containing latin1 (ISO-8859-1) characters.
       * The byte array must not be modified or otherwise referenced or used after the String is created.
       * If COMPACT_STRINGS is true the coder will be LATIN1 and the byte array is the string value;
       * otherwise the contents are inflated to create a UTF16 string.
       */ 
    public String newStringLatin1NoRepl(byte[] src) {
         if (COMPACT_STRINGS)
             return new String(src, LATIN1);
         return new String(StringLatin1.inflate(src, 0, src.length), UTF16);
    }

Creating strings from other encodings that may or have encoding errors should continue to use the current function and handle CCE as required.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1768911569

From alanb at openjdk.org  Wed Oct 18 16:43:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Oct 2023 16:43:19 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
 
Message-ID: 

On Wed, 18 Oct 2023 16:27:58 GMT, Roger Riggs  wrote:

> The new usages that are driving this change would be better served by a method dedicated to creating latin1 strings from a caller provided byte array. The JavaLangAccess shared secret interface is already overused, but it is cleaner, more maintainable, and fit for purpose to add a method than to contort the exception handling as proposed.

We have to be very careful with proposals like this as it means code outside of java.lang having access to the underlying bytes. I think other alternatives needs to be explored to avoid this and related concerns.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1768937914

From mcimadamore at openjdk.org  Wed Oct 18 17:33:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 17:33:27 GMT
Subject: Integrated: 8318458: Update javac and java manpages with restricted
 method options
In-Reply-To: 
References: 
Message-ID: <7Cqe5x3ukFjqBTZBckg4U-6kJsLX_WcwesgCg8o07J8=.5b66ee5f-f6b3-421b-935e-f8ebd7d5f3e5@github.com>

On Wed, 18 Oct 2023 15:32:34 GMT, Maurizio Cimadamore  wrote:

> This PR updates the man pages for `javac` and `java` to document:
> * the new `javac` warning for restricted methods (`-Xlint:restricted`)
> * the `java` option to allow access to restricted methods without warnings (`--enable-native-access`)

This pull request has now been integrated.

Changeset: 278de7ac
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/278de7acd21cc6f938aca561d02248e75c119e11
Stats:     21 lines in 2 files changed: 17 ins; 0 del; 4 mod

8318458: Update javac and java manpages with restricted method options

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jdk/pull/16249

From igavrilin at openjdk.org  Wed Oct 18 17:35:58 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Wed, 18 Oct 2023 17:35:58 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
> 
> Tests:
> Performance tests on t-head board:
> With intrinsics:
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
> 
> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
> 
> Regression tests: tier1, hotspot:tier2 on risc-v board.
> 
> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
> 
> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> index 6cd1353907e..0bee25366bf 100644
> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>  
>      @Benchmark
>      public double  copySignDouble() {
> -        return  Math.copySign(double81, doubleNegative12);
> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>      }
>  
>      @Benchmark
>      public float  copySignFloat() {
> -        return  Math.copySign(floatNegative99, float1);
> +        return  Math.copySign(floatNegative99, float1) + Math.copySign(eFloat, float1) + Math.copySign...

Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:

  Remove some effects and assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16186/files
  - new: https://git.openjdk.org/jdk/pull/16186/files/b0a53a0c..c0a2ab95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16186/head:pull/16186

PR: https://git.openjdk.org/jdk/pull/16186

From sgehwolf at openjdk.org  Wed Oct 18 17:37:30 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 18 Oct 2023 17:37:30 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v6]
In-Reply-To: 
References: 
Message-ID: 

> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.jmod        jdk.unsupported...

Severin Gehwolf has updated the pull request incrementally with four additional commits since the last revision:

 - Add a message when a run-image based link is being performed
 - Add hint to the modified file case
 - AddJmodResourcesPlugin => AddRunImageResourcesPlugin rename
 - --add-jmod-resources => --add-run-image-resources rename
   
   Also rename jmod_resources to runimage_resources

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/ef1bca8c..b82efb08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=04-05

  Stats: 31 lines in 6 files changed: 17 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From mcimadamore at openjdk.org  Wed Oct 18 17:38:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 17:38:28 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v5]
In-Reply-To: <3ntu2qv_pOdX5bQm01UhCTZ2rSvp6REJ6_tghzYxQIA=.94354eb1-ffbc-4bff-951f-2cb887a3f414@github.com>
References: 
 <3ntu2qv_pOdX5bQm01UhCTZ2rSvp6REJ6_tghzYxQIA=.94354eb1-ffbc-4bff-951f-2cb887a3f414@github.com>
Message-ID: 

On Wed, 18 Oct 2023 09:00:09 GMT, Per Minborg  wrote:

>> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
>> 
>> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
>> 
>> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
>> 
>> 
>> // Resolve ambiguity
>> var function = Function.of(String::isEmpty); // Function
>> var predicate = Predicate.of(String::isEmpty); // Predicate
>> 
>> // Fluent composition
>> var chained = Function.of(String::length)       // Function
>>                    .andThen(Integer::byteValue);      // Function
>> 
>> 
>> Please see the original bug report for a comprehensive description of these proposed changes.
>> 
>> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
>> 
>> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pretty

I'm a little concerned that these methods will prove less useful than it seems (or _differently_ useful). That is, the main reason for adding them would be to allow fluent composition of operators, functions, etc. But this functional composition has limitation: since the target type only applies to the _last_ call in a chain, all the intermediate call will be type-checked without a target type. This means that any attempt to use implicit lambdas, or inexact method references in the intermediate links or the composition chain will result in inference errors and will, in my opinion, provide a not very smooth user experience.

So, if we exclude method chaining, the other reason as to why the new factories might be useful is that they allow developers to write slightly more succinct code, especially when combined with `var`. E.g. 


BinaryOperator bop = Integer::sum


vs:


var bop = BinaryOperator.of(Integer::sum)


(of course the comparison gets more and more favorable for the latter the more type arguments appear in the functional interface type used in the LHS).

What about the vastly more common case where a functional interface is accepted as parameter to a Java method? Well, here it doesn't feel like the new factories add that much because:

* if no composition is needed, then target-type inference does its job just fine (e.g. just pass a lambda, or a method reference to the method)
* if composition is required, then, for the reasons above, the fluent style is hit and miss, and lack of target-typing support across the _entire_ method chain will result in inference errors.

So, I suspect I'm not 100% sold on the usefulness of these new factories.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16213#issuecomment-1769025400

From jvernee at openjdk.org  Wed Oct 18 17:38:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 17:38:24 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  add s390 support

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/07d06216..65bd8d83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=05-06

  Stats: 124 lines in 2 files changed: 53 ins; 60 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From sjayagond at openjdk.org  Wed Oct 18 17:38:27 2023
From: sjayagond at openjdk.org (Sidraya Jayagond)
Date: Wed, 18 Oct 2023 17:38:27 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 14:29:01 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add PPC impl
>  - add missing file

Add s390x port from here
[S390x_Panama_heap_segments.txt](https://github.com/openjdk/jdk/files/13031418/S390x_Panama_heap_segments.txt)

All tests are passing on linux S390x. One single test case is failing on Big Endian:
test TestLayoutPaths.testBadAlignmentOfRoot(): failure. Similar to PPC Big Endian.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1768978247

From jvernee at openjdk.org  Wed Oct 18 17:38:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 17:38:28 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 17:04:52 GMT, Sidraya Jayagond  wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add PPC impl
>>  - add missing file
>
> Add s390x port from here
> [S390x_Panama_heap_segments.txt](https://github.com/openjdk/jdk/files/13031418/S390x_Panama_heap_segments.txt)
> 
> All tests are passing on linux S390x. One single test case is failing on Big Endian:
> test TestLayoutPaths.testBadAlignmentOfRoot(): failure. Similar to PPC Big Endian.

@sid8606 Thanks, I've added it to the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1768985519

From rriggs at openjdk.org  Wed Oct 18 17:39:13 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Oct 2023 17:39:13 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
 
 
Message-ID: 

On Wed, 18 Oct 2023 16:39:47 GMT, Alan Bateman  wrote:

> We have to be very careful with proposals like this as it means code outside of java.lang having access to the underlying bytes. I think other alternatives needs to be explored to avoid this and related concerns.

Yes, adding another method in the "NoRepl" family needs to be done with care and be narrowly focused.
JLA already exposes several methods that allow the contents of strings to be read from the underlying value or created from caller provided buffers. All to avoid extra allocations and copying.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1769026087

From aturbanov at openjdk.org  Wed Oct 18 17:45:22 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 18 Oct 2023 17:45:22 GMT
Subject: RFR: 8316144: Remove unused field
 jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element._Depth
In-Reply-To: 
References: 
Message-ID: 

On Tue, 12 Sep 2023 20:04:54 GMT, Andrey Turbanov  wrote:

> A field `short _Depth` in the `jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element` class is unused and can be removed.

Anyone want to review? I will integrate tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15692#issuecomment-1769036124

From ramadasu.nandagiri at hpe.com  Wed Oct 18 17:47:46 2023
From: ramadasu.nandagiri at hpe.com (Nandagiri, Ramadasu (NSDi))
Date: Wed, 18 Oct 2023 17:47:46 +0000
Subject: Request for JCK17 tests exclusion
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

Hi Alan,

Thanks for your response and the suggestion. I have copied, net-dev on my original mail. I will wait for a response from net-dev group.

Regards,
Ramdas
________________________________
From: Alan Bateman 
Sent: Wednesday, October 18, 2023 8:51 PM
To: Nandagiri, Ramadasu (NSDi) ; net-dev at openjdk.org ; core-libs-dev at openjdk.org 
Cc: Bhat, Suma Mudakare Bheema (NSDi) ; Gragg, Jeffrey 
Subject: Re: Request for JCK17 tests exclusion

On 18/10/2023 15:55, Nandagiri, Ramadasu (NSDi) wrote:
Hi,

Please see the discussion in the following mails. One of the TCK test cases, api/java_net/MulticastSocket/ClassLevel.html is failing on NonStop platform as NonStop doesn't support IP_MULTICAST_ALL option.

We would like this test case to be excluded from TCK. Please share your thoughts on this request.

I realize you have been directed here but this is not the right place to discuss TCK exclusion requests.

>From the mails you forwarded then it looks like there are issues with the multicast support in your port to NonStop. The IP_MULTICAST_ALL socket option you mention is used in the Linux port to avoid interference when two sockets are bound to the same port but joined to different multicast groups. Linux is an outlier in this scenario so the socket option is set to prevent the interference. My guess is that few people here will know NonStop but you could being porting questions on this code to net-dev.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mcimadamore at openjdk.org  Wed Oct 18 17:49:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 17:49:43 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v5]
In-Reply-To: <3ntu2qv_pOdX5bQm01UhCTZ2rSvp6REJ6_tghzYxQIA=.94354eb1-ffbc-4bff-951f-2cb887a3f414@github.com>
References: 
 <3ntu2qv_pOdX5bQm01UhCTZ2rSvp6REJ6_tghzYxQIA=.94354eb1-ffbc-4bff-951f-2cb887a3f414@github.com>
Message-ID: 

On Wed, 18 Oct 2023 09:00:09 GMT, Per Minborg  wrote:

>> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
>> 
>> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
>> 
>> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
>> 
>> 
>> // Resolve ambiguity
>> var function = Function.of(String::isEmpty); // Function
>> var predicate = Predicate.of(String::isEmpty); // Predicate
>> 
>> // Fluent composition
>> var chained = Function.of(String::length)       // Function
>>                    .andThen(Integer::byteValue);      // Function
>> 
>> 
>> Please see the original bug report for a comprehensive description of these proposed changes.
>> 
>> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
>> 
>> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pretty

With my language hat on, there are two things that are problematic here:
1. lack of target-typing propagation can cause some use-site to be less fluent (as they have to break up different higher-order method calls)
2. the overload resolution logic for higher-order methods is sometimes overly conservative - e.g. it will refuse to look at the body of a lambda expression with implicit parameter types if there's two possible target types, even though the two targets agree on the inferred parameter types (this problem is described in the third part of https://openjdk.org/jeps/302).

Now, addressing (1) require big changes to the inference scheme (it is especially problematic if a "yet to be inferred" type-variable acts as a receiver for the subsequent method in the chain).

But addressing (2) is far more doable, and should lead to a nice usability boost in a lot of situations where the language currently says "sorry, ambiguous". And it feels this is the main motivation for adding the new APIs in the first place. If so, perhaps considering a language change/enhancement could provide better return on investment?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16213#issuecomment-1769043653

From ihse at openjdk.org  Wed Oct 18 18:01:43 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 18 Oct 2023 18:01:43 GMT
Subject: RFR: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 15:43:12 GMT, Naoto Sato  wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix makefile for the tz data path

Build changes look good now

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1685776520

From duke at openjdk.org  Wed Oct 18 18:13:38 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 18 Oct 2023 18:13:38 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v7]
In-Reply-To: 
References: 
Message-ID: 

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

Glavo has updated the pull request with a new target base 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 branch 'openjdk:master' into latin1-no-repl
 - Use newStringLatin1NoRepl in UUID
 - Merge branch 'openjdk:master' into latin1-no-repl
 - Merge branch 'openjdk:master' into latin1-no-repl
 - Merge branch 'openjdk:master' into latin1-no-repl
 - update javadoc
 - clean newStringNoRepl1
 - clean newStringNoRepl1
 - Rename jla to JLA
 - Create new method JavaLangAccess::newStringLatin1NoRepl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14655/files
  - new: https://git.openjdk.org/jdk/pull/14655/files/96788ddd..e92a877c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=05-06

  Stats: 298265 lines in 6160 files changed: 131638 ins; 106892 del; 59735 mod
  Patch: https://git.openjdk.org/jdk/pull/14655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655

PR: https://git.openjdk.org/jdk/pull/14655

From duke at openjdk.org  Wed Oct 18 18:14:13 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 18 Oct 2023 18:14:13 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v5]
In-Reply-To: 
References: 
Message-ID: 

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

Glavo has updated the pull request with a new target base 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 'openjdk:master' into zip-utils
 - Merge branch 'openjdk:master' into zip-utils
 - Merge branch 'openjdk:master' into zip-utils
 - Merge branch 'openjdk:master' into zip-utils
 - use ByteArrayLittleEndian in ZipUtils

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14632/files
  - new: https://git.openjdk.org/jdk/pull/14632/files/49520bbf..efdc185b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=03-04

  Stats: 43740 lines in 1476 files changed: 27635 ins; 7715 del; 8390 mod
  Patch: https://git.openjdk.org/jdk/pull/14632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14632/head:pull/14632

PR: https://git.openjdk.org/jdk/pull/14632

From duke at openjdk.org  Wed Oct 18 18:17:24 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 18 Oct 2023 18:17:24 GMT
Subject: RFR: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException [v5]
In-Reply-To: 
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 14:22:10 GMT, Shaojin Wen  wrote:

>> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix from @AlanBateman 's review

Should we revisit https://github.com/openjdk/jdk/pull/14655?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16209#issuecomment-1769082700

From smarks at openjdk.org  Wed Oct 18 18:23:29 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 18 Oct 2023 18:23:29 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 16 Oct 2023 11:13:57 GMT, Mark Sheppard  wrote:

>> Matthew Donovan has updated the pull request with a new target base 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 socket-params
>>  - Merge branch 'master' into socket-params
>>  - added javadocs to new methods
>>  - 8303525: Refactor/cleanup open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java
>
> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 77:
> 
>> 75: 
>> 76:     public void testRmiCommunication(RMIServerSocketFactory serverFactory) throws Exception {
>> 77:             Hello stub = (Hello)UnicastRemoteObject.exportObject(new HelloImpl(),
> 
> by not retaining an explicit reference to the test rmi server, you are exposing it to potentially being GCed during the test execution  and potentially prior to client invocation... this might sound fanciful but  this has been observed in a few scenarios due to the GC  changes ... althought it doesn't seem to have been an issue, the structure of the test appears to be inherently racy, with the potential for the client invocation to getting ahead of the server with the rmi server launching background threads.
> Anyways, caution on not retaining a sever reference and GC interference.

Yes, this can still happen even if the reference to the server object is held in a local variable. It's unlikely to occur, but to prevent any possibility of unexpected GC, you need to use reachabilityFence. Something like:

    HelloImpl server = new HelloImpl();
    try {
        // ... use server ...
    } finally {
        Reference.reachabilityFence(server);
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1364336386

From smarks at openjdk.org  Wed Oct 18 18:28:12 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 18 Oct 2023 18:28:12 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 17 Oct 2023 11:33:00 GMT, Matthew Donovan  wrote:

>> test/lib/jdk/test/lib/Asserts.java line 588:
>> 
>>> 586:         }
>>> 587:         // fail() throws a RuntimeException so this is unreachable.
>>> 588:         return null;
>> 
>> Hm, this is unfortunate. Even though this method throws along all code paths, the compiler doesn't do this analysis. Even though this "never happens" there's still a question of "but what if?" (I guess it could happen if somebody in the future were to modify the code above.) I'd suggest unconditionally throwing an exception here (probably InternalError) to be more explicit. Returning null will result in an inexplicable NPE if somebody dereferences the return value.
>
> Actually, this is a mistake. If I call `fail()` immediately after the test method executes (because an exception wasn't thrown), the RuntimeException which will promptly be caught in my try/catch and that isn't what we want. I'm moving that invocation to the end which looks and works a lot better.

Ah, right. Throwing unconditionally at the end of the method is the right thing. Good catch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1364340476

From joehw at openjdk.org  Wed Oct 18 18:28:07 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 18 Oct 2023 18:28:07 GMT
Subject: RFR: 8316144: Remove unused field
 jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element._Depth
In-Reply-To: 
References: 
Message-ID: 

On Tue, 12 Sep 2023 20:04:54 GMT, Andrey Turbanov  wrote:

> A field `short _Depth` in the `jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element` class is unused and can be removed.

Sorry, I didn't realize Lance was calling on me to review, certainly a reminder to read 'mention' ("@someone") emails :-)

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15692#pullrequestreview-1685826235

From naoto at openjdk.org  Wed Oct 18 18:29:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Oct 2023 18:29:43 GMT
Subject: Integrated: 8317979: Use TZ database style abbreviations in the CLDR
 locale provider
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 19:57:12 GMT, Naoto Sato  wrote:

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

This pull request has now been integrated.

Changeset: ce8ebebc
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/ce8ebebc77f4ef73852364f6188b43c482337350
Stats:     161 lines in 6 files changed: 138 ins; 1 del; 22 mod

8317979: Use TZ database style abbreviations in the CLDR locale provider

Reviewed-by: rriggs, joehw, lancea, erikj, iris, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/16206

From mdonovan at openjdk.org  Wed Oct 18 19:05:06 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 18 Oct 2023 19:05:06 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  added reachability fence for the rmi server object

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14932/files
  - new: https://git.openjdk.org/jdk/pull/14932/files/c2610f36..783348e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14932&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14932&range=03-04

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14932/head:pull/14932

PR: https://git.openjdk.org/jdk/pull/14932

From prr at openjdk.org  Wed Oct 18 20:07:43 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Oct 2023 20:07:43 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
Message-ID: 

8318364: Add an FFM-based implementation of harfbuzz OpenType layout

-------------

Commit messages:
 - remove tailing white space
 - use scaling
 - Fix windows build, remove perf. logging
 - Add test, fix bug
 - use allocateFrom
 - add offset param
 - suppressed restricted warnings, now builds but not running yet
 - Adapt to changed API for FFM final
 - Merge
 - Use exact VarHandles
 - ... and 7 more: https://git.openjdk.org/jdk/compare/77fa44fd...8d826865

Changes: https://git.openjdk.org/jdk/pull/15476/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15476&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318364
  Stats: 1374 lines in 7 files changed: 1372 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15476/head:pull/15476

PR: https://git.openjdk.org/jdk/pull/15476

From prr at openjdk.org  Wed Oct 18 20:07:45 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Oct 2023 20:07:45 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Aug 2023 02:55:34 GMT, Sergey Bylokhov  wrote:

> @prrace did you check how this change affects the performance, especially startup? I have experimented with Panama for littlecms: https://bugs.openjdk.org/browse/JDK-8313344 and found that the biggest issue is a cold start, 8 ms vs 100ms. An example of the report: https://jmh.morethan.io/?gists=4df0f27789cc4b0ca91fc5b2d677fe39,900b547e073cc1567971f46bfea151db

Hmm. I didn't notice this comment until today. No emails for drafts ?
Probably I should not have posted this PR even as draft if it is going to get attention as it isn't really ready for that.

But yes, I had already measured startup + warmup and noticed that's an issue.
It may be doesn't matter so much for OpenType layout as other things that are always on the critical path, but it is definitely a concern.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1702114439

From serb at openjdk.org  Wed Oct 18 20:07:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Oct 2023 20:07:43 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race  wrote:

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

@prrace did you check how this change affects the performance, especially startup? I have experimented with Panama for littlecms: https://bugs.openjdk.org/browse/JDK-8313344 and found that the biggest issue is a cold start, 8 ms vs 100ms. An example of the report: https://jmh.morethan.io/?gists=4df0f27789cc4b0ca91fc5b2d677fe39,900b547e073cc1567971f46bfea151db

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1698413107

From serb at openjdk.org  Wed Oct 18 20:07:46 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Oct 2023 20:07:46 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 1 Sep 2023 03:45:24 GMT, Phil Race  wrote:

> Probably I should not have posted this PR even as draft if it is going to get attention as it isn't really ready for that.

No! That is really interesting proposal and discussion!

BTW this PR is not in the draft state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1702168525

From pminborg at openjdk.org  Wed Oct 18 20:07:57 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 18 Oct 2023 20:07:57 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race  wrote:

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

src/java.desktop/share/classes/sun/font/HBShaper.java line 55:

> 53: public class HBShaper {
> 54: 
> 55:     /*

Nice with the original C struct as a comment.

src/java.desktop/share/classes/sun/font/HBShaper.java line 65:

> 63:      * };
> 64:      */
> 65:    private static final UnionLayout VarIntLayout = MemoryLayout.unionLayout(

I was a bit confused by the naming. Suggest `VarIntLayout` -> `VAR_INT_LAYOUT`

src/java.desktop/share/classes/sun/font/HBShaper.java line 108:

> 106:     ).withName("hb_glyph_info_t");
> 107: 
> 108:     private static VarHandle getVarHandle(MemoryLayout layout, String name) {

This method could take a `SequenceLayout` instead of a `MemoryLayout` as it only works for SeequenceLayouts.

src/java.desktop/share/classes/sun/font/HBShaper.java line 129:

> 127:     private static MethodHandle jdk_hb_shape_handle;
> 128: 
> 129:     private static FunctionDescriptor get_nominal_glyph_fd;

All the `*_fd` variables could be converted into local variables.

src/java.desktop/share/classes/sun/font/HBShaper.java line 130:

> 128: 
> 129:     private static FunctionDescriptor get_nominal_glyph_fd;
> 130:     private static MethodHandle get_nominal_glyph_mh;

Declaring all these `final` would improve performance.  For example

`private static final FunctionDescription GET_NOMINAL_GLYPH_MH;`

src/java.desktop/share/classes/sun/font/HBShaper.java line 314:

> 312:         Font2D font2D = scopedFont2D.get();
> 313:         int glyphID = font2D.charToGlyph(unicode);
> 314:         MemorySegment glyphIDPtr = glyph.reinterpret(4);

As a general comment, it is better to use slicing rather than reinterpret.

src/java.desktop/share/classes/sun/font/HBShaper.java line 405:

> 403:     private static final ScopedValue scopedFontStrike = ScopedValue.newInstance();
> 404:     private static final ScopedValue scopedGVData = ScopedValue.newInstance();
> 405:     private static final ScopedValue scopedStartPt = ScopedValue.newInstance();

Using only one ScopedValue and storing a `record(Font2D font2D, FontStrike fontStrike, GVData gvData, Point2D.float point2d) {}` of the various objects will provide much better performance.

src/java.desktop/share/classes/sun/font/HBShaper.java line 428:

> 426:          * The alternative of creating bound method handles is far too slow.
> 427:          */ 
> 428:         ScopedValue.where(scopedFont2D, font2D)

I think a static `ConcurrentHashMap` would provide better performance. We could clean up the key when the value is used.  Use the Thread.threadId() as the key.

src/java.desktop/share/classes/sun/font/HBShaper.java line 468:

> 466:          * done with it.
> 467:          */
> 468:         MemorySegment data_ptr = data_ptr_out.reinterpret(ADDRESS.byteSize());

Suggest using `.asSlice()` here as it is an unrestricted and safer method.

src/java.desktop/share/classes/sun/font/HBShaper.java line 474:

> 472:         }
> 473:         byte[] data = font2D.getTableBytes(tag);
> 474:         if (data == null) {

No setting data_ptr_out to NULL here?

src/java.desktop/share/classes/sun/font/HBShaper.java line 524:

> 522:         }
> 523:  
> 524:         private synchronized MemorySegment getFace() {

We are already synchronized via the `faceMap`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1309776173
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1309775469
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1309770631
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1309774045
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1309772610
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1309813499
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1310541406
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1310545668
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1309793358
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1309791413
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1309810009

From jvernee at openjdk.org  Wed Oct 18 20:07:58 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 20:07:58 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race  wrote:

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

src/java.desktop/share/classes/sun/font/HBShaper.java line 310:

> 308:         SequenceLayout glyphInfosLayout = MemoryLayout.sequenceLayout(maxinfo, GlyphInfoLayout);
> 309:         codePointHandle = getVarHandle(glyphInfosLayout, "codepoint");
> 310:         clusterHandle = getVarHandle(glyphInfosLayout, "cluster");

There are better ways to do this in the latest API, by using the extra offset parameter and `MemoryLayout::scaleHandle`.

I suggest changing this to:

Suggestion:

        x_offsetHandle = getVarHandle(PositionLayout, "x_offset");
        y_offsetHandle = getVarHandle(PositionLayout, "y_offset");
        x_advanceHandle = getVarHandle(PositionLayout, "x_advance");
        y_advanceHandle = getVarHandle(PositionLayout, "y_advance");
        codePointHandle = getVarHandle(GlyphInfoLayout, "codepoint");
        clusterHandle = getVarHandle(GlyphInfoLayout, "cluster");


And then in `getVarHandle`:


    private static VarHandle getVarHandle(MemoryLayout enclosing, String name) {
        VarHandle h = layout.varHandle(PathElement.groupElement(name));
        // scale offset by the size of 'enclosing'
        h = MethodHandles.collectCoordinates(h, 1, enclosing.scaleHandle());
        /* insert 0 offset so don't need to pass arg every time */
        return MethodHandles.insertCoordinates(h, 1, 0L).withInvokeExactBehavior();
    }


(hope I eyeballed that correctly...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1361989861

From prr at openjdk.org  Wed Oct 18 20:07:59 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Oct 2023 20:07:59 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
 
Message-ID: <6iv2em-LyZx-TkZUB9X-rrjEgcNyfB_W4qga5GZO5Yk=.d9429817-6b70-4e40-b0ce-37f6c76fefc0@github.com>

On Tue, 17 Oct 2023 11:50:20 GMT, Jorn Vernee  wrote:

>> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
>
> src/java.desktop/share/classes/sun/font/HBShaper.java line 310:
> 
>> 308:         SequenceLayout glyphInfosLayout = MemoryLayout.sequenceLayout(maxinfo, GlyphInfoLayout);
>> 309:         codePointHandle = getVarHandle(glyphInfosLayout, "codepoint");
>> 310:         clusterHandle = getVarHandle(glyphInfosLayout, "cluster");
> 
> There are better ways to do this in the latest API, by using the extra offset parameter and `MemoryLayout::scaleHandle`.
> 
> I suggest changing this to:
> 
> Suggestion:
> 
>         x_offsetHandle = getVarHandle(PositionLayout, "x_offset");
>         y_offsetHandle = getVarHandle(PositionLayout, "y_offset");
>         x_advanceHandle = getVarHandle(PositionLayout, "x_advance");
>         y_advanceHandle = getVarHandle(PositionLayout, "y_advance");
>         codePointHandle = getVarHandle(GlyphInfoLayout, "codepoint");
>         clusterHandle = getVarHandle(GlyphInfoLayout, "cluster");
> 
> 
> And then in `getVarHandle`:
> 
> 
>     private static VarHandle getVarHandle(MemoryLayout enclosing, String name) {
>         VarHandle h = layout.varHandle(PathElement.groupElement(name));
>         // scale offset by the size of 'enclosing'
>         h = MethodHandles.collectCoordinates(h, 1, enclosing.scaleHandle());
>         /* insert 0 offset so don't need to pass arg every time */
>         return MethodHandles.insertCoordinates(h, 1, 0L).withInvokeExactBehavior();
>     }
> 
> 
> (hope I eyeballed that correctly...)

I've just pushed this change, but I'm unclear why it is "better". It seems more obscure to me.
I've added a somewhat expanded comment of what I guess this does to help
me and others understand what it does. Please take a look to see if it makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1362900089

From jvernee at openjdk.org  Wed Oct 18 20:08:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 20:08:00 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: <6iv2em-LyZx-TkZUB9X-rrjEgcNyfB_W4qga5GZO5Yk=.d9429817-6b70-4e40-b0ce-37f6c76fefc0@github.com>
References: 
 
 <6iv2em-LyZx-TkZUB9X-rrjEgcNyfB_W4qga5GZO5Yk=.d9429817-6b70-4e40-b0ce-37f6c76fefc0@github.com>
Message-ID: 

On Tue, 17 Oct 2023 22:53:30 GMT, Phil Race  wrote:

>  I'm unclear why it is "better". It seems more obscure to me.

Ok. I think it's better because it doesn't require creating a maximum size sequence layout in order to then make a var handle out of, which is a bit of a hack IMO. One that was required in the previous version of the API.

This kind of use-case, where the size of the sequence is not known statically, is one of the reasons why we added the extra base offset parameter to the var handles.

Another way of writing this would be to use the base var handle, with its extra leading offset parameter, and then pass e.g. `i * PositionLayout.byteSize()` as the offset at every call site (where `i` is the array index). The two extra combination steps essentially create a var handle with that behavior baked in.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1363114533

From prr at openjdk.org  Wed Oct 18 20:08:01 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Oct 2023 20:08:01 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
 
 <6iv2em-LyZx-TkZUB9X-rrjEgcNyfB_W4qga5GZO5Yk=.d9429817-6b70-4e40-b0ce-37f6c76fefc0@github.com>
 
Message-ID: 

On Wed, 18 Oct 2023 03:43:15 GMT, Jorn Vernee  wrote:

> > I'm unclear why it is "better". It seems more obscure to me.
> 
> Ok. I think it's better because it doesn't require creating a maximum size sequence layout in order to then make a var handle out of, which is a bit of a hack IMO. One that was required in the previous version of the API.

Not sure which "previous" that was, but in JDK 21 I did not need to specify a size.
The need to do that was something that came in as of JDK 22 and I thought it a bit of a backwards step perhaps motivated to help devs understand the sizes involved but given the arithmetic involved in general I am not sure it was justified.

> 
> This kind of use-case, where the size of the sequence is not known statically, is one of the reasons why we added the extra base offset parameter to the var handles.

The previous API dealt with that just fine. And equivalently as far as I can  tell.
The base offset parameter may have other uses but I need  its relevance to this explained to me,

> Another way of writing this would be to use the base var handle, with its extra leading offset parameter, and then pass e.g. `i * PositionLayout.byteSize()` as the offset at every call site (where `i` is the array index). The two extra combination steps essentially create a var handle with that behavior baked in.

OK, but now you have a VarHandle intended for use on a SequenceLayout (ie array) of Struct and are disguising it for some reason that isn't (sufficiently?) obvious at an API level and definitely isn't obvious at a performance level.
Is there some fundamental reason why the 21 API could not internally be reduced to the same ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1363167938

From jvernee at openjdk.org  Wed Oct 18 20:08:02 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 20:08:02 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
 
 <6iv2em-LyZx-TkZUB9X-rrjEgcNyfB_W4qga5GZO5Yk=.d9429817-6b70-4e40-b0ce-37f6c76fefc0@github.com>
 
 
Message-ID: 

On Wed, 18 Oct 2023 04:44:30 GMT, Phil Race  wrote:

>>>  I'm unclear why it is "better". It seems more obscure to me.
>> 
>> Ok. I think it's better because it doesn't require creating a maximum size sequence layout in order to then make a var handle out of, which is a bit of a hack IMO. One that was required in the previous version of the API.
>> 
>> This kind of use-case, where the size of the sequence is not known statically, is one of the reasons why we added the extra base offset parameter to the var handles.
>> 
>> Another way of writing this would be to use the base var handle, with its extra leading offset parameter, and then pass e.g. `i * PositionLayout.byteSize()` as the offset at every call site (where `i` is the array index). The two extra combination steps essentially create a var handle with that behavior baked in.
>
>> > I'm unclear why it is "better". It seems more obscure to me.
>> 
>> Ok. I think it's better because it doesn't require creating a maximum size sequence layout in order to then make a var handle out of, which is a bit of a hack IMO. One that was required in the previous version of the API.
> 
> Not sure which "previous" that was, but in JDK 21 I did not need to specify a size.
> The need to do that was something that came in as of JDK 22 and I thought it a bit of a backwards step perhaps motivated to help devs understand the sizes involved but given the arithmetic involved in general I am not sure it was justified.
> 
>> 
>> This kind of use-case, where the size of the sequence is not known statically, is one of the reasons why we added the extra base offset parameter to the var handles.
> 
> The previous API dealt with that just fine. And equivalently as far as I can  tell.
> The base offset parameter may have other uses but I need  its relevance to this explained to me,
> 
>> Another way of writing this would be to use the base var handle, with its extra leading offset parameter, and then pass e.g. `i * PositionLayout.byteSize()` as the offset at every call site (where `i` is the array index). The two extra combination steps essentially create a var handle with that behavior baked in.
> 
> OK, but now you have a VarHandle intended for use on a SequenceLayout (ie array) of Struct and are disguising it for some reason that isn't (sufficiently?) obvious at an API level and definitely isn't obvious at a performance level.
> Is there some fundamental reason why the 21 API could not internally be reduced to the same ?

Requiring users to specify the size of the sequence layout was done in order to dispel the illusion that there was any kind of special handling for a sequence layout created without a size. e.g. if you try to allocate with it, what should happen? Should we detect that this as a special case? Or just crush with an OOME? This is something other users ran into in practice, and removing the size-less factory revealed some latent bugs in the tests as well. So, I feel that overall, dropping the size-less factory was the right move. This was more or less an orthogonal decision to the decision of adding the base offset parameter.

The previous JDK 21 API asked users to construct layouts for memory of which they did not know the layout in advance. e.g. when creating a var handle from a sequence layout with the maximum number of elements, the in-memory array that is being accessed is likely not actually an array with the maximum number of elements? The special max element sequence layout is just a workaround used to be able to create an indexed var handle.

Another example is a 2-dimensional matrix with a dynamic row and column size. How should this be represented using a memory layout? We can't use the max element sequence layout trick in that case, since the size of the inner sequence affects the scaling of the index for the outer sequence.

The core issue is that, to get good performance, a user needs to construct the layout and derive var handles in advance, but at the same time it is not possible to represent a layout with a 'dynamic' size. We went back and forth on ideas in order to add better support for dynamic sizes in the layout API. But in the end, all the things we tried ended up being convoluted, and had their own set of corner cases that were ill-addressed.

So, the conclusion we arrived at was that layouts are better left alone, and should only be used to represent memory layouts that are 'static'/fixed and known up front. In that case a user can declare the layout, and all the var handles they need, in advance, and stick them into `static final` fields, which is required to get good performance.

But then the question becomes: what about structural access to memory whose layout can _not_ be represented statically? Even in those cases, often there is a part of the structure of the memory layout that is fixed, and part of the layout that is dynamic. The memory layout API can still be used for the fixed part, and then the extra base offset parameter can be used to handle the dynamic part, by injecting external/ad-hoc offset computations into the var handle access.

As far as I can tell in this patch, the var handles that are created are for arrays whose size is not known statically, so this would fall into the territory that is address by the extra base offset parameter. That's why I think it is 'better' to use that mechanism. It avoids the need for the max element sequence layout workaround, which, as you found, also became more cumbersome due to the decision to drop the size-less sequence layout factory. At the end of the day, it was just a suggestion. I think you should stick with the version you prefer. (technically the version using the sequence layout adds an extra bounds check, but I think it will be folded away by C2).

If the var handle combinator steps look obscure, I think that is a good indicator that we perhaps need an extra `arrayVarHandle` convenience method that does the combination steps.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1363287236

From mcimadamore at openjdk.org  Wed Oct 18 20:08:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 20:08:05 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
Message-ID: <1KVYxaDDdK5rq9Fs3j6XTGaLuGXS4w8rv0GlPkffQmg=.985e1f57-a82e-4df8-a400-4471502bfd65@github.com>

On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race  wrote:

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

src/java.desktop/share/classes/sun/font/HBShaper.java line 425:

> 423:                 float startY = (float)startPt.getY();
> 424: 
> 425:                 MemorySegment matrix = arena.allocateArray(JAVA_FLOAT, mat.length);

There should be an overload of `allocateArray` which takes a Java array directly and then copies it off-heap after allocation. In Java 22 this method is called `allocateFrom` and is much more optimized (as it avoids zeroing of memory). But, even in 21, the call to copy seems redundant - you can just use the correct overload of `SegmentAllocator::allocateArray`

src/java.desktop/share/classes/sun/font/HBShaper.java line 613:

> 611:          for (int i=0; i 612:              int storei = i + initialCount;
> 613:              int cluster = (int)clusterHandle.get(glyphInfoArr, i) - offset;

All the var handle calls in this loop are not exact - e.g. they use a `int` offset instead of a `long` one. Because of this, the memory access cannot be fully optimized. Adding a cast to `long` on all offsets coordinates yields a significant performance boost.

To avoid issues like these, it is recommended to set up the var handle using the `VarHandle::withInvokeExactBehavior` method, which will cause an exception to be thrown in case there's a type mismatch (similar to `MethodHandle::invokeExact`).

src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c line 80:

> 78:      int flags,
> 79:      int slot,
> 80:      hb_font_get_nominal_glyph_func_t nominal_fn,

It shouldn't be necessary to pass all the functions here. Note that the upcalls are now effectively static (due to the use of scope values). It would be more efficient to create the array of functions once and for all in Java code (either directly, by creating a memory segment and storing all the function pointers in there, or indirectly, by calling the `_hb_jdk_get_font_funcs` native function). But, we don't need to create a function array each time we call the `shape` function (as all the functions in the array are going to be the same after all). If you do that, you can replace all the `_fn` parameters in here with a single function pointer array parameter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1342570582
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1345600057
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1342567487

From prr at openjdk.org  Wed Oct 18 20:12:52 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Oct 2023 20:12:52 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race  wrote:

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

I've added a test, which although it does not check the rendering is correct, it checks that the rendering would be identical in both the JNI and FFM cases. So if it's wrong it would already be wrong.
And the test covers multiple scripts and passes on all core platforms (macOS, Windows, Linux)
And I've separately manually verified that the rendering is as expected - if you have the fonts available.

At this point the code is ready for review for consideration for pushing to JDK 22.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1769241548
PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1769244133

From prr at openjdk.org  Wed Oct 18 20:12:54 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Oct 2023 20:12:54 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
 
 <6iv2em-LyZx-TkZUB9X-rrjEgcNyfB_W4qga5GZO5Yk=.d9429817-6b70-4e40-b0ce-37f6c76fefc0@github.com>
 
 
 
Message-ID: <4DmVPegxpQ1fzHenGMEALSoxy82D3SP84yt_xALc4Ok=.a9f0bc2a-b68c-443c-a528-00b63a2aa86b@github.com>

On Wed, 18 Oct 2023 06:16:15 GMT, Jorn Vernee  wrote:

>>> > I'm unclear why it is "better". It seems more obscure to me.
>>> 
>>> Ok. I think it's better because it doesn't require creating a maximum size sequence layout in order to then make a var handle out of, which is a bit of a hack IMO. One that was required in the previous version of the API.
>> 
>> Not sure which "previous" that was, but in JDK 21 I did not need to specify a size.
>> The need to do that was something that came in as of JDK 22 and I thought it a bit of a backwards step perhaps motivated to help devs understand the sizes involved but given the arithmetic involved in general I am not sure it was justified.
>> 
>>> 
>>> This kind of use-case, where the size of the sequence is not known statically, is one of the reasons why we added the extra base offset parameter to the var handles.
>> 
>> The previous API dealt with that just fine. And equivalently as far as I can  tell.
>> The base offset parameter may have other uses but I need  its relevance to this explained to me,
>> 
>>> Another way of writing this would be to use the base var handle, with its extra leading offset parameter, and then pass e.g. `i * PositionLayout.byteSize()` as the offset at every call site (where `i` is the array index). The two extra combination steps essentially create a var handle with that behavior baked in.
>> 
>> OK, but now you have a VarHandle intended for use on a SequenceLayout (ie array) of Struct and are disguising it for some reason that isn't (sufficiently?) obvious at an API level and definitely isn't obvious at a performance level.
>> Is there some fundamental reason why the 21 API could not internally be reduced to the same ?
>
> Requiring users to specify the size of the sequence layout was done in order to dispel the illusion that there was any kind of special handling for a sequence layout created without a size. e.g. if you try to allocate with it, what should happen? Should we detect that this as a special case? Or just crush with an OOME? This is something other users ran into in practice, and removing the size-less factory revealed some latent bugs in the tests as well. So, I feel that overall, dropping the size-less factory was the right move. This was more or less an orthogonal decision to the decision of adding the base offset parameter.
> 
> The previous JDK 21 API asked users to construct layouts for memory of which they did not know the layout in advance. e.g. when creating a var handle from a sequence layout with the maximum number of elements, the in-memory array that is being accessed is likely not actually an array with the maximum number of elements? The special max element sequence layout is just a workaround used to be able to create an indexed var handle.
> 
> Another example is a 2-dimensional matrix with a dynamic row and column size. How should this be represented using a memory layout? We can't use the max element sequence layout trick in that case, since the size of the inner sequence affects the scaling of the index for the outer sequence.
> 
> The core issue is that, to get good performance, a user needs to construct the layout and derive var handles in advance, but at the same time it is not possible to represent a layout with a 'dynamic' size. We went back and forth on ideas in order to add better support for dynamic sizes in the layout API. But in the end, all the things we tried ended up being convoluted, and had their own set of corner cases that were ill-addressed.
> 
> So, the conclusion we arrived at was that layouts are better left alone, and should only be used to represent memory layouts that are 'static'/fixed and known up front. In that case a user can declare the layout, and all the var handles they need, in advance, and stick them into `static final` fields, which is required to get good performance.
> 
> But then the question becomes: what about structural access to memory whose layout can _not_ be represented statically? Even in those cases, often there is a part of the structure of the memory layout that is fixed, and part of the layout that is dynamic. The memory layout API can still be used for the fixed part, and then the extra base offset parameter can...

I feel like I'm starting to learn that once you've got your VarHandle from FFM, you need to head over to java.lang.invoke and hunt around to see what tricks you can do with it.
The less I have to do that the better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1364478566

From msheppar at openjdk.org  Wed Oct 18 20:13:47 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 18 Oct 2023 20:13:47 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v5]
In-Reply-To: 
References: 
 
Message-ID: <-C7GLg1BTSdInjxQGdoitS9_nJWTwDtwy_7PnUOQ9m4=.da364299-d1b4-41ac-ae4f-45de0c4c4fb7@github.com>

On Wed, 18 Oct 2023 19:05:06 GMT, Matthew Donovan  wrote:

>> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added reachability fence for the rmi server object

submitted some test runs to mach5 for these changes and they have succeeded

-------------

Marked as reviewed by msheppar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14932#pullrequestreview-1686055124

From msheppar at openjdk.org  Wed Oct 18 20:13:50 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 18 Oct 2023 20:13:50 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 18 Oct 2023 18:20:49 GMT, Stuart Marks  wrote:

>> test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 77:
>> 
>>> 75: 
>>> 76:     public void testRmiCommunication(RMIServerSocketFactory serverFactory) throws Exception {
>>> 77:             Hello stub = (Hello)UnicastRemoteObject.exportObject(new HelloImpl(),
>> 
>> by not retaining an explicit reference to the test rmi server, you are exposing it to potentially being GCed during the test execution  and potentially prior to client invocation... this might sound fanciful but  this has been observed in a few scenarios due to the GC  changes ... althought it doesn't seem to have been an issue, the structure of the test appears to be inherently racy, with the potential for the client invocation to getting ahead of the server with the rmi server launching background threads.
>> Anyways, caution on not retaining a sever reference and GC interference.
>
> Yes, this can still happen even if the reference to the server object is held in a local variable. It's unlikely to occur, but to prevent any possibility of unexpected GC, you need to use reachabilityFence. Something like:
> 
>     HelloImpl server = new HelloImpl();
>     try {
>         // ... use server ...
>     } finally {
>         Reference.reachabilityFence(server);
>     }
> 
> I would go ahead and add this out of an abundance of caution.

yes, good advice on reachability fence ... added some -Xcomp args to test runs and no failures detected

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14932#discussion_r1364479317

From smarks at openjdk.org  Wed Oct 18 21:38:50 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 18 Oct 2023 21:38:50 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v6]
In-Reply-To: 
References: 
 
Message-ID: <6PuSbRXz4-7_pbZlgdd6nOosMCWSaknzaQsXmXAM8yg=.5692f866-43d1-4059-9a0a-a25703d5e3ab@github.com>

On Wed, 18 Oct 2023 15:24:14 GMT, Per Minborg  wrote:

>> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
>> 
>> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
>> 
>> We need to benchmark this solution to better understand its implications.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add 'fresh' to implSpec

In TreeMap, should the cached entrySet and navigableKeySet fields also be removed?

I'm not sure about removal of the clone() method. Certainly it will need to be adjusted to remove mention of the now-removed fields, but I haven't thought through all the compatibility implications of removing the method entirely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-1769358474

From abimpoudis at openjdk.org  Wed Oct 18 22:12:10 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 18 Oct 2023 22:12:10 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v25]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/248971be..fa6256b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=23-24

  Stats: 38 lines in 2 files changed: 37 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From prr at openjdk.org  Wed Oct 18 22:25:48 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Oct 2023 22:25:48 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race  wrote:

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

That's interesting. As soon as this went RFR, skara started to send all the emails from several weeks of already resolved discussions but with a current timestamp, like we all were able to speed read, and type 100 wpm ..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1769493805

From duke at openjdk.org  Wed Oct 18 22:38:34 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 18 Oct 2023 22:38:34 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v8]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: <5H3imcAE77nIAX1tf-Bq7nrwcVkjkZ5clunYp4jpV-Q=.16de2dbe-308d-4bc0-8845-b4cddee675ec@github.com>

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  recipe ("\1.\1\1")

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/013ceffb..89cad442

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=06-07

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From ccheung at openjdk.org  Wed Oct 18 23:28:39 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 18 Oct 2023 23:28:39 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request with a new target base 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:

 - comments from Alan and Ioi; add missing @run tag in the test
 - Merge branch 'master' into improve-CDS-module-graph
 - better way to check if a module is a JDK module
 - initial review comments from Ioi
 - 8316969: Improve CDS module graph support for --module option

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16016/files
  - new: https://git.openjdk.org/jdk/pull/16016/files/eb653492..ad4a58d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=00-01

  Stats: 31416 lines in 1056 files changed: 18295 ins; 6497 del; 6624 mod
  Patch: https://git.openjdk.org/jdk/pull/16016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16016/head:pull/16016

PR: https://git.openjdk.org/jdk/pull/16016

From ccheung at openjdk.org  Wed Oct 18 23:28:41 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 18 Oct 2023 23:28:41 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <_LcZRqiK6FIY1zt1NqwJ5GjCJiosbcITj2eHT86hA3s=.c4857f0b-7c3a-42df-acb6-acd5c92924c2@github.com>

On Tue, 17 Oct 2023 23:34:56 GMT, Ioi Lam  wrote:

>> Calvin Cheung has updated the pull request with a new target base 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:
>> 
>>  - comments from Alan and Ioi; add missing @run tag in the test
>>  - Merge branch 'master' into improve-CDS-module-graph
>>  - better way to check if a module is a JDK module
>>  - initial review comments from Ioi
>>  - 8316969: Improve CDS module graph support for --module option
>
> src/hotspot/share/classfile/modules.cpp line 567:
> 
>> 565: #endif
>> 566: 
>> 567: void Modules::dump_module_name() {
> 
> This function should be `dump_main_module_name()`

I've changed the function name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1364682871

From ccheung at openjdk.org  Wed Oct 18 23:28:44 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 18 Oct 2023 23:28:44 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 06:26:24 GMT, Alan Bateman  wrote:

>> Calvin Cheung has updated the pull request with a new target base 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:
>> 
>>  - comments from Alan and Ioi; add missing @run tag in the test
>>  - Merge branch 'master' into improve-CDS-module-graph
>>  - better way to check if a module is a JDK module
>>  - initial review comments from Ioi
>>  - 8316969: Improve CDS module graph support for --module option
>
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 472:
> 
>> 470: 
>> 471:         // if -Xshare:dump and mainModule are specified, check if the mainModule
>> 472:         // is a builtin JDK module. If so, set canArchive to true so that the
> 
> There is no notion of "built-in JDK module" so I think change the comment to say that it checks if the main module is in the run-time image and not on the upgrade module path.
> 
> URI schemes are compared without regard to case so it should be equalsIgnoreCase("jrt").

Fixed both.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1364683166

From jvernee at openjdk.org  Wed Oct 18 23:47:47 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 18 Oct 2023 23:47:47 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: <4DmVPegxpQ1fzHenGMEALSoxy82D3SP84yt_xALc4Ok=.a9f0bc2a-b68c-443c-a528-00b63a2aa86b@github.com>
References: 
 
 <6iv2em-LyZx-TkZUB9X-rrjEgcNyfB_W4qga5GZO5Yk=.d9429817-6b70-4e40-b0ce-37f6c76fefc0@github.com>
 
 
 
 <4DmVPegxpQ1fzHenGMEALSoxy82D3SP84yt_xALc4Ok=.a9f0bc2a-b68c-443c-a528-00b63a2aa86b@github.com>
Message-ID: 

On Wed, 18 Oct 2023 20:08:26 GMT, Phil Race  wrote:

>> Requiring users to specify the size of the sequence layout was done in order to dispel the illusion that there was any kind of special handling for a sequence layout created without a size. e.g. if you try to allocate with it, what should happen? Should we detect that this as a special case? Or just crush with an OOME? This is something other users ran into in practice, and removing the size-less factory revealed some latent bugs in the tests as well. So, I feel that overall, dropping the size-less factory was the right move. This was more or less an orthogonal decision to the decision of adding the base offset parameter.
>> 
>> The previous JDK 21 API asked users to construct layouts for memory of which they did not know the layout in advance. e.g. when creating a var handle from a sequence layout with the maximum number of elements, the in-memory array that is being accessed is likely not actually an array with the maximum number of elements? The special max element sequence layout is just a workaround used to be able to create an indexed var handle.
>> 
>> Another example is a 2-dimensional matrix with a dynamic row and column size. How should this be represented using a memory layout? We can't use the max element sequence layout trick in that case, since the size of the inner sequence affects the scaling of the index for the outer sequence.
>> 
>> The core issue is that, to get good performance, a user needs to construct the layout and derive var handles in advance, but at the same time it is not possible to represent a layout with a 'dynamic' size. We went back and forth on ideas in order to add better support for dynamic sizes in the layout API. But in the end, all the things we tried ended up being convoluted, and had their own set of corner cases that were ill-addressed.
>> 
>> So, the conclusion we arrived at was that layouts are better left alone, and should only be used to represent memory layouts that are 'static'/fixed and known up front. In that case a user can declare the layout, and all the var handles they need, in advance, and stick them into `static final` fields, which is required to get good performance.
>> 
>> But then the question becomes: what about structural access to memory whose layout can _not_ be represented statically? Even in those cases, often there is a part of the structure of the memory layout that is fixed, and part of the layout that is dynamic. The memory layout API can still be used for the fixed part, and then the extra bas...
>
> I feel like I'm starting to learn that once you've got your VarHandle from FFM, you need to head over to java.lang.invoke and hunt around to see what tricks you can do with it.
> The less I have to do that the better.

I wouldn't say it's necessarily required, but I would say that it is what ultimately leads to the most succinct code. I'm probably biased towards using the java.lang.invoke tricks though.

The java.lang.invoke combinator API is a convenient way to generate wrapper functions around a VarHandle (or MethodHandle). But, you could also write out the wrapper functions manually. In this case that shouldn't be too much of a problem given that the code only uses `get`. You could declare basic field VarHandles created with `layout.varHandle(PathElement.groupElement(name));`, and then write the wrapper functions like so:


public static int getYOffset(MemorySegment glyphPosArr, int index) {
    long posArrOffset = PositionLayout.scale(0, index); // or just: index * PositionLayout.byteSize()
    return (int) y_offsetHandle.get(glyphPosArr, posArrOffset);
}


You would need 6 of these in total. Or, just use the implementation 'inline', without the wrapper functions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1364697148

From mcimadamore at openjdk.org  Wed Oct 18 23:58:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 23:58:48 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race  wrote:

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

src/java.desktop/share/classes/sun/font/HBShaper.java line 110:

> 108: 
> 109:     private static VarHandle getVarHandle(StructLayout struct, String name) {
> 110:         VarHandle h = struct.varHandle(PathElement.groupElement(name));

Note that, strictly speaking, these combiners are _not_ required. If you just call `MemoryLayout::varHandle`, you get back a var handle that takes a `MemorySegment` and a `long` offset. So, you can, if you want, adapt the var handle so that the offset parameter becomes something else. But you could also just leave the var handle as is. Then, in the loop that is doing the access, you can do this:


for (int i = 0 ; i < limit ; i++) {
   x_offsetHandle.get(segment, PositionLayout.scale(0, i));
   y_offsetHandle.get(segment, PositionLayout.scale(0, i));
   ...
}

That is, use the offset hole to your advantage, to pass the struct base offset (obtained by scaling the enclosing struct layout by the value of the loop induction variable).

(That said, I understand that working with logical indices is a common operation, and that this is made a bit harder by the recent API changes. We should consider, as @JornVernee mentioned, adding back a more general `MemoryLayout::arrayElementVarHandle` which will give you the var handle you need - with coordinates `MemorySegment` and `long` - a logical index, not an offset).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1364702729

From smarks at openjdk.org  Thu Oct 19 00:34:50 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 19 Oct 2023 00:34:50 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 19:05:06 GMT, Matthew Donovan  wrote:

>> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added reachability fence for the rmi server object

Looks good!

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14932#pullrequestreview-1686449985

From fyang at openjdk.org  Thu Oct 19 00:39:49 2023
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 19 Oct 2023 00:39:49 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v3]
In-Reply-To: 
References: 
 
Message-ID: <8hnDLf3rfTCEGEOMPYJIbdK0xiqd1YM_p6oZz6zTx4M=.43701960-46d8-4a6b-8373-f03649eb75c3@github.com>

On Wed, 18 Oct 2023 17:35:58 GMT, Ilya Gavrilin  wrote:

>> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
>> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
>> 
>> Tests:
>> Performance tests on t-head board:
>> With intrinsics:
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
>> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
>> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
>> 
>> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
>> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
>> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
>> 
>> Regression tests: tier1, hotspot:tier2 on risc-v board.
>> 
>> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
>> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
>> 
>> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> index 6cd1353907e..0bee25366bf 100644
>> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>>  
>>      @Benchmark
>>      public double  copySignDouble() {
>> -        return  Math.copySign(double81, doubleNegative12);
>> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>>      }
>>  
>>      @Benchmark
>>      public float  copySignFloat() {
>> -        return  Math.copySign(floatNegative99, float1);
>> +        return  ...
>
> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove some effects and assert

Updated change looks good. Thanks.
JMH data on hifive unmatched for reference:

Before:
Benchmark                 (seed)   Mode  Cnt      Score       Error   Units
MathBench.copySignDouble       0  thrpt    8  79728.042 ?  8211.438  ops/ms
MathBench.copySignFloat        0  thrpt    8  79516.930 ? 13163.477  ops/ms
MathBench.sigNumDouble         0  thrpt    8  58204.403 ?  6795.238  ops/ms
MathBench.signumFloat          0  thrpt    8  57882.056 ?  3635.354  ops/ms

After:
Benchmark                 (seed)   Mode  Cnt       Score       Error   Units
MathBench.copySignDouble       0  thrpt    8  104301.832 ?  7170.917  ops/ms
MathBench.copySignFloat        0  thrpt    8  103008.851 ? 11722.187  ops/ms
MathBench.signumDouble         0  thrpt    8   64465.030 ?  6849.148  ops/ms
MathBench.signumFloat          0  thrpt    8   63987.290 ?  4298.311  ops/ms

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16186#pullrequestreview-1686455232

From dholmes at openjdk.org  Thu Oct 19 01:25:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Oct 2023 01:25:55 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 17:38:24 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add s390 support

src/hotspot/share/gc/shared/gcLocker.cpp line 139:

> 137:     // has called `jni_unlock`, but not yet finished the call, e.g. initiating
> 138:     // a GCCause::_gc_locker GC.
> 139:     log_debug_jni("Blocked from entering critical section while waiting on GC.");

Seems unrelated to current MR - leftover debugging code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1364763295

From almatvee at openjdk.org  Thu Oct 19 01:41:30 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 19 Oct 2023 01:41:30 GMT
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild [v2]
In-Reply-To: 
References: 
Message-ID: <9F-RIuf2KBQErlzi9sfrnz0qgIen-aI5y0HMj1biGAk=.14dc6e4b-f148-4049-8d49-c6952092ccf4@github.com>

> - Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
> - If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
>> Error: "codesign" failed with following output:
>> test: no identity found
> 
>> Error: "productbuild" failed with following output:
>> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
> - Added error handling not to allow invalid combinations of signing options.
> - Updated signing tests to test new changes.

Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8311877
 - 8311877: [macos] Add CLI options to provide signing identity directly to codesign and productbuild

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16085/files
  - new: https://git.openjdk.org/jdk/pull/16085/files/57abfbad..4cd56e25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16085&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16085&range=00-01

  Stats: 42104 lines in 1446 files changed: 26275 ins; 7631 del; 8198 mod
  Patch: https://git.openjdk.org/jdk/pull/16085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16085/head:pull/16085

PR: https://git.openjdk.org/jdk/pull/16085

From jvernee at openjdk.org  Thu Oct 19 01:55:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 19 Oct 2023 01:55:56 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 19 Oct 2023 01:22:46 GMT, David Holmes  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add s390 support
>
> src/hotspot/share/gc/shared/gcLocker.cpp line 139:
> 
>> 137:     // has called `jni_unlock`, but not yet finished the call, e.g. initiating
>> 138:     // a GCCause::_gc_locker GC.
>> 139:     log_debug_jni("Blocked from entering critical section while waiting on GC.");
> 
> Seems unrelated to current MR - leftover debugging code?

Yes, good catch. Leftover from when this patch used GCLocker (which turned out to be not needed in the end)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1364783686

From liach at openjdk.org  Thu Oct 19 02:18:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Oct 2023 02:18:47 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 Oct 2023 11:56:14 GMT, Claes Redestad  wrote:

> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 725:

> 723:     }
> 724: 
> 725:     private static MethodHandle noPrefixPrepender(Class cl) {

Should the no-prefix prependers be declared package-private now that they are accessed via JLA? Otherwise we might accidentally change those APIs and break stuff.

Another way to guard is to make stringConcatHelper find methods with a lookup restricted to package access by changing this line: https://github.com/openjdk/jdk/blob/e25a49a993f270c33f7929e629fb3075a11fdec9/src/java.base/share/classes/java/lang/StringConcatHelper.java#L589
to

return MethodHandles.lookup()
        .dropLookupMode(MethodHandles.Lookup.PRIVATE)
        .findStatic(StringConcatHelper.class, name, methodType);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16244#discussion_r1364794177

From pminborg at openjdk.org  Thu Oct 19 06:38:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Oct 2023 06:38:25 GMT
Subject: RFR: 8318454: TestLayoutPaths broken on Big Endian platforms after
 JDK-8317837
Message-ID: 

This PR suggests a fix for a failing test on platforms with big endian.

The PR also contains a drive-by removal of an unused import.

-------------

Commit messages:
 - Remove unused imports
 - Fix problem with endianness

Changes: https://git.openjdk.org/jdk/pull/16259/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16259&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318454
  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16259.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16259/head:pull/16259

PR: https://git.openjdk.org/jdk/pull/16259

From duke at openjdk.org  Thu Oct 19 06:38:35 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 19 Oct 2023 06:38:35 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v3]
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: <2AUQJBYNCZaitrlfcUz1__tb_IEPw3BGfp1R8xmiMS0=.c2bf986d-2164-4931-b3f9-3d1f32cd345f@github.com>

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix FormatterBuilder testcase handle lineSeparator on windows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/fd5a5f29..d8d3ef4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15776/head:pull/15776

PR: https://git.openjdk.org/jdk/pull/15776

From pminborg at openjdk.org  Thu Oct 19 06:42:04 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Oct 2023 06:42:04 GMT
Subject: RFR: 8317993: Add capturing factories to classes in
 java.util.function package [v5]
In-Reply-To: <3ntu2qv_pOdX5bQm01UhCTZ2rSvp6REJ6_tghzYxQIA=.94354eb1-ffbc-4bff-951f-2cb887a3f414@github.com>
References: 
 <3ntu2qv_pOdX5bQm01UhCTZ2rSvp6REJ6_tghzYxQIA=.94354eb1-ffbc-4bff-951f-2cb887a3f414@github.com>
Message-ID: <3fa-h73-Dg4RZIIUazl5MsdKfzWiaM1xUGcYkFJtj7k=.4a5c9f45-1b6b-41d9-9152-b63ba41955bf@github.com>

On Wed, 18 Oct 2023 09:00:09 GMT, Per Minborg  wrote:

>> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
>> 
>> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
>> 
>> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
>> 
>> 
>> // Resolve ambiguity
>> var function = Function.of(String::isEmpty); // Function
>> var predicate = Predicate.of(String::isEmpty); // Predicate
>> 
>> // Fluent composition
>> var chained = Function.of(String::length)       // Function
>>                    .andThen(Integer::byteValue);      // Function
>> 
>> 
>> Please see the original bug report for a comprehensive description of these proposed changes.
>> 
>> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
>> 
>> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pretty

As much as I liked this idea from the beginning, I am getting increasingly skeptical. By introducing methods like these, we risk code compatibility over time and this feature would instead turn into a straight jacket. The objectives of this PR can be reached by language changes rather than the library approach attempted here. It would, for example, be possible to consider adding diamond operator/type inference in casts. So rather than `Function.of(String::isEmpty) `, one might write `(Function<>)String::isEmpty` which will be inferred to `(Function)String::isEmpty`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16213#issuecomment-1770157285

From aturbanov at openjdk.org  Thu Oct 19 06:44:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 19 Oct 2023 06:44:46 GMT
Subject: Integrated: 8316144: Remove unused field
 jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element._Depth
In-Reply-To: 
References: 
Message-ID: 

On Tue, 12 Sep 2023 20:04:54 GMT, Andrey Turbanov  wrote:

> A field `short _Depth` in the `jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element` class is unused and can be removed.

This pull request has now been integrated.

Changeset: 80bd22d0
Author:    Andrey Turbanov 
URL:       https://git.openjdk.org/jdk/commit/80bd22d093b696b40a3380527b19d8d2c4e138f9
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8316144: Remove unused field jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element._Depth

Reviewed-by: lancea, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/15692

From liach at openjdk.org  Thu Oct 19 07:11:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Oct 2023 07:11:18 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.newString/getBytesUTF8NoRepl to
 FailFast
Message-ID: 

Please review a patch that renames `JavaLangAccess::newStringUTF8NoRepl` and `getBytesUTF8NoRepl` to `newStringUTF8FailFast` and `getBytesUTF8FailFast` to accurately describe these APIs. This also renames other associated methods.

NoRepl means "no replication", which is not what these APIs are for. They instead expose the fail-fast construction fast-path in String, allowing `ZipCoder` to quickly throw encoding exceptions wrapped in `IllegalArgumentException` without going through decoders and encoders.

In addition, there is already `newStringNoRepl` and `getBytesNoRepl` in `JavaLangAccess` that actually avoids copying arrays for trusted usages, further increasing the confusion. Given these internal APIs are frequently used in recent contributions around improving string performance, I believe a rename of these APIs is necessary.

Pinging @cl4es for a review since you use this particular API the most often.

-------------

Commit messages:
 - Rename JavaLangAccess.newString/getBytesUTF8NoRepl to FailFast

Changes: https://git.openjdk.org/jdk/pull/16260/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16260&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318486
  Stats: 13 lines in 4 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16260/head:pull/16260

PR: https://git.openjdk.org/jdk/pull/16260

From aoqi at openjdk.org  Thu Oct 19 07:23:03 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 19 Oct 2023 07:23:03 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 17 Oct 2023 07:03:50 GMT, yaqsun  wrote:

>> `%define _build_id_links none` must be added to a spec file in LinuxResourceTest.java file. not on `rpmbuild` command line
>
>> `%define _build_id_links none` must be added to a spec file in LinuxResourceTest.java file. not on `rpmbuild` command line
> 
> `%define _build_id_links none` has been added to a spec file in LinuxResourceTest.java file. Please review.

@yaqsun , I suggest you synchronize with the latest code and trigger testing before integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15832#issuecomment-1770209686

From mbaesken at openjdk.org  Thu Oct 19 07:25:39 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 19 Oct 2023 07:25:39 GMT
Subject: RFR: JDK-8318415: Adjust describing comment of os_getChildren
 after 8315026
In-Reply-To: <8pQJPDwoYZ69TAln8NHL8WnuD8Ts0dkR9jC5jxrZL7o=.1c6793df-94f5-4c37-8e7a-ea47e8408cdd@github.com>
References: <8pQJPDwoYZ69TAln8NHL8WnuD8Ts0dkR9jC5jxrZL7o=.1c6793df-94f5-4c37-8e7a-ea47e8408cdd@github.com>
Message-ID: <7UKeEkzUUiBgd6vm5lzybFEgfC4XzkclhrS8zU5hn1U=.db3f39a1-a20a-493d-b61c-1bb3e33e1e10@github.com>

On Wed, 18 Oct 2023 08:18:47 GMT, Matthias Baesken  wrote:

> 8315026 adjusted and improved the describings comments already for AIX/Linux. But macOS was not adjusted.

Hi Roger, thanks for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16236#issuecomment-1770209550

From mbaesken at openjdk.org  Thu Oct 19 07:25:40 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 19 Oct 2023 07:25:40 GMT
Subject: Integrated: JDK-8318415: Adjust describing comment of os_getChildren
 after 8315026
In-Reply-To: <8pQJPDwoYZ69TAln8NHL8WnuD8Ts0dkR9jC5jxrZL7o=.1c6793df-94f5-4c37-8e7a-ea47e8408cdd@github.com>
References: <8pQJPDwoYZ69TAln8NHL8WnuD8Ts0dkR9jC5jxrZL7o=.1c6793df-94f5-4c37-8e7a-ea47e8408cdd@github.com>
Message-ID: 

On Wed, 18 Oct 2023 08:18:47 GMT, Matthias Baesken  wrote:

> 8315026 adjusted and improved the describings comments already for AIX/Linux. But macOS was not adjusted.

This pull request has now been integrated.

Changeset: 47bb1a1c
Author:    Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/47bb1a1cefa242c39c22a8f2aa08d7d357c260b9
Stats:     15 lines in 2 files changed: 8 ins; 0 del; 7 mod

8318415: Adjust describing comment of os_getChildren after 8315026

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/16236

From liach at openjdk.org  Thu Oct 19 07:28:00 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Oct 2023 07:28:00 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.newString/getBytesUTF8NoRepl
 to FailFast
In-Reply-To: 
References: 
Message-ID: <57STR4aMtZ68n1J2al2cAed6kE6C5XRD_y29XKuyRlo=.b0debe5e-7439-48c3-9d14-3da6c6b2f498@github.com>

On Thu, 19 Oct 2023 07:04:50 GMT, Chen Liang  wrote:

> Please review a patch that renames `JavaLangAccess::newStringUTF8NoRepl` and `getBytesUTF8NoRepl` to `newStringUTF8FailFast` and `getBytesUTF8FailFast` to accurately describe these APIs. This also renames other associated methods.
> 
> NoRepl means "no replication", which is not what these APIs are for. They instead expose the fail-fast construction fast-path in String, allowing `ZipCoder` to quickly throw encoding exceptions wrapped in `IllegalArgumentException` without going through decoders and encoders.
> 
> In addition, there is already `newStringNoRepl` and `getBytesNoRepl` in `JavaLangAccess` that actually avoids copying arrays for trusted usages, further increasing the confusion. Given these internal APIs are frequently used in recent contributions around improving string performance, I believe a rename of these APIs is necessary.
> 
> Pinging @cl4es for a review since you use this particular API the most often.

On second thought, an alternative solution is to consolidate the String access internal APIs into:

String newStringFailFast(byte[] bytes, Charset charset, boolean trusted);
byte[] getBytesFailFast(String string, Charset charset, boolean trusted);

These APIs will immediately throw encoding errors as an IAE with a CCE cause instead of silently performing a character substitution.

There are 2 flags we want to consider: `trusted` and `failFast`. 
| | `trusted == true` | `trusted == false`|
|-|--------|--------|
| __`failFast == true`__| Usual trusted scenario | Usual fail-fast scenario |
| __`failFast == false`__| Meaningless, if failure happens, trust is already broken | Can be done with public APIs | 

In conclusion, we can simplify the internal API to assume `failFast` holds true and only request a `trusted` flag.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16260#issuecomment-1770215673

From alanb at openjdk.org  Thu Oct 19 07:28:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Oct 2023 07:28:01 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.newString/getBytesUTF8NoRepl
 to FailFast
In-Reply-To: 
References: 
Message-ID: 

On Thu, 19 Oct 2023 07:04:50 GMT, Chen Liang  wrote:

> NoRepl means "no replication", which is not what these APIs are for. 

I assume it's "no replace", meaning it reports the error rather than use the coder's replacement value.

I agree it could be renamed but I think look at CodingErrorAction for the established terminology. Your suggestion for "fast fail" will create confusion as maintainers will be forced to wonder if there is potential for failing lazily.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16260#issuecomment-1770217422

From pminborg at openjdk.org  Thu Oct 19 07:42:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Oct 2023 07:42:49 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v7]
In-Reply-To: 
References: 
Message-ID: 

> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
> 
> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
> 
> We need to benchmark this solution to better understand its implications.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Reintroduce AbstractMap::clone

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15614/files
  - new: https://git.openjdk.org/jdk/pull/15614/files/fabdb59b..b1648e6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=05-06

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15614/head:pull/15614

PR: https://git.openjdk.org/jdk/pull/15614

From pminborg at openjdk.org  Thu Oct 19 07:54:34 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Oct 2023 07:54:34 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v8]
In-Reply-To: 
References: 
Message-ID: 

> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
> 
> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
> 
> We need to benchmark this solution to better understand its implications.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Move back clone to original position

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15614/files
  - new: https://git.openjdk.org/jdk/pull/15614/files/b1648e6a..e9cda02f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=06-07

  Stats: 20 lines in 1 file changed: 10 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15614/head:pull/15614

PR: https://git.openjdk.org/jdk/pull/15614

From pminborg at openjdk.org  Thu Oct 19 08:14:41 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Oct 2023 08:14:41 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v9]
In-Reply-To: 
References: 
Message-ID: 

> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
> 
> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
> 
> We need to benchmark this solution to better understand its implications.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove caching from CHM and CSLM

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15614/files
  - new: https://git.openjdk.org/jdk/pull/15614/files/e9cda02f..949dee26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=07-08

  Stats: 23 lines in 2 files changed: 0 ins; 18 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15614/head:pull/15614

PR: https://git.openjdk.org/jdk/pull/15614

From duke at openjdk.org  Thu Oct 19 08:59:49 2023
From: duke at openjdk.org (yaqsun)
Date: Thu, 19 Oct 2023 08:59:49 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27 [v3]
In-Reply-To: 
References: 
Message-ID: 

> on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
> It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
> But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.

yaqsun has updated the pull request with a new target base 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 'openjdk:master' into 8316563
 - fixed Whitespace error: del tab
 - 8316563: test tools/jpackage/linux/LinuxResourceTest.java fails on RHEL8 and Fedora 27
 - fixed Whitespace error: del tab
 - 8316563: test tools/jpackage/linux/LinuxResourceTest.java fails on RHEL8 and Fedora 27

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15832/files
  - new: https://git.openjdk.org/jdk/pull/15832/files/06b690b5..f853fb13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15832&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15832&range=01-02

  Stats: 60114 lines in 1685 files changed: 36198 ins; 14821 del; 9095 mod
  Patch: https://git.openjdk.org/jdk/pull/15832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15832/head:pull/15832

PR: https://git.openjdk.org/jdk/pull/15832

From liach at openjdk.org  Thu Oct 19 09:03:38 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Oct 2023 09:03:38 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.newString/getBytesUTF8NoRepl
 to FailFast
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 07:25:38 GMT, Alan Bateman  wrote:

> I assume it's "no replace", meaning it reports the error rather than use the coder's replacement value.

This revelation is too important; I might have to reevaluate my choices, for many contributors have assumed that `NoRepl` was intended to avoid duplication instead of error substitution. That said, I will look for better solutions to en/decode strings with error reporting, or creating strings or accessing the arrays with trust (as seen in a recent FFM API string writing JLA addition)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16260#issuecomment-1770372141

From duke at openjdk.org  Thu Oct 19 09:27:42 2023
From: duke at openjdk.org (yaqsun)
Date: Thu, 19 Oct 2023 09:27:42 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27
In-Reply-To: 
References: 
 
 
Message-ID: <-3BCiydhAYroPJ-ijEJYUvwmTJCQidD_2LrEHIGEqvM=.8cc56cc6-5809-440d-aff4-82e58c958603@github.com>

On Tue, 17 Oct 2023 07:03:50 GMT, yaqsun  wrote:

>> `%define _build_id_links none` must be added to a spec file in LinuxResourceTest.java file. not on `rpmbuild` command line
>
>> `%define _build_id_links none` must be added to a spec file in LinuxResourceTest.java file. not on `rpmbuild` command line
> 
> `%define _build_id_links none` has been added to a spec file in LinuxResourceTest.java file. Please review.

> @yaqsun , I suggest you synchronize with the latest code and trigger testing before integration.

I've synced to the latest code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15832#issuecomment-1770417439

From psandoz at openjdk.org  Thu Oct 19 09:29:52 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Oct 2023 09:29:52 GMT
Subject: RFR: 8318421 : AbstractPipeline.sourceStageSpliterator() chases
 pointers needlessly
In-Reply-To: <_51DHI2JBgmgI3Gqc4dvWH59J2ujKMxBUCYrzmD2l_w=.2eb7c6f2-e02d-4927-b31d-05b3f2e5bb07@github.com>
References: <_51DHI2JBgmgI3Gqc4dvWH59J2ujKMxBUCYrzmD2l_w=.2eb7c6f2-e02d-4927-b31d-05b3f2e5bb07@github.com>
Message-ID: 

On Wed, 18 Oct 2023 10:14:08 GMT, Viktor Klang  wrote:

> Removes a few unnecessary dereferences of `sourceStage`.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16241#pullrequestreview-1685995672

From vklang at openjdk.org  Thu Oct 19 09:29:52 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Oct 2023 09:29:52 GMT
Subject: RFR: 8318421 : AbstractPipeline.sourceStageSpliterator() chases
 pointers needlessly
In-Reply-To: <_51DHI2JBgmgI3Gqc4dvWH59J2ujKMxBUCYrzmD2l_w=.2eb7c6f2-e02d-4927-b31d-05b3f2e5bb07@github.com>
References: <_51DHI2JBgmgI3Gqc4dvWH59J2ujKMxBUCYrzmD2l_w=.2eb7c6f2-e02d-4927-b31d-05b3f2e5bb07@github.com>
Message-ID: 

On Wed, 18 Oct 2023 10:14:08 GMT, Viktor Klang  wrote:

> Removes a few unnecessary dereferences of `sourceStage`.

@PaulSandoz Care to review this one? :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16241#issuecomment-1768129782

From vklang at openjdk.org  Thu Oct 19 09:29:51 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Oct 2023 09:29:51 GMT
Subject: RFR: 8318421 : AbstractPipeline.sourceStageSpliterator() chases
 pointers needlessly
Message-ID: <_51DHI2JBgmgI3Gqc4dvWH59J2ujKMxBUCYrzmD2l_w=.2eb7c6f2-e02d-4927-b31d-05b3f2e5bb07@github.com>

Removes a few unnecessary dereferences of `sourceStage`.

-------------

Commit messages:
 - Avoiding unnecessary pointer-chasing in sourceStageSpliterator() and avoiding a check-then-act in close()

Changes: https://git.openjdk.org/jdk/pull/16241/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16241&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318421
  Stats: 10 lines in 1 file changed: 1 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16241.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16241/head:pull/16241

PR: https://git.openjdk.org/jdk/pull/16241

From vklang at openjdk.org  Thu Oct 19 09:31:10 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Oct 2023 09:31:10 GMT
Subject: RFR: 8318420 : AbstractPipeline invokes overridden method in
 constructor
Message-ID: 

This PR corrects so that `opIsStateful()` is not invoked as a part of the java.util.stream.AbstractPipeline constructor?as `opIsStateful()` is intended to be overridden by subclasses, and as their own constructors have not run when their superclass constructor runs, this means that `opIsStateful()` cannot base its return value on any class members of the subclass.

Since `opIsStateful()` is only needed for parallel streams, we can therefor defer the invocation of `opIsStateful()` until evaluation-time, and as such we can remove the need for having an instance field to store the result of the invocation?making Stream instances potentially a tiny bit smaller, reducing Stream-construction overhead, while still preserving semantics.

-------------

Commit messages:
 - Avoids calling opIsStateful() during AbstractPipeline constructor

Changes: https://git.openjdk.org/jdk/pull/16239/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16239&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318420
  Stats: 24 lines in 1 file changed: 15 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16239.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16239/head:pull/16239

PR: https://git.openjdk.org/jdk/pull/16239

From psandoz at openjdk.org  Thu Oct 19 09:31:10 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 19 Oct 2023 09:31:10 GMT
Subject: RFR: 8318420 : AbstractPipeline invokes overridden method in
 constructor
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 Oct 2023 09:45:53 GMT, Viktor Klang  wrote:

> This PR corrects so that `opIsStateful()` is not invoked as a part of the java.util.stream.AbstractPipeline constructor?as `opIsStateful()` is intended to be overridden by subclasses, and as their own constructors have not run when their superclass constructor runs, this means that `opIsStateful()` cannot base its return value on any class members of the subclass.
> 
> Since `opIsStateful()` is only needed for parallel streams, we can therefor defer the invocation of `opIsStateful()` until evaluation-time, and as such we can remove the need for having an instance field to store the result of the invocation?making Stream instances potentially a tiny bit smaller, reducing Stream-construction overhead, while still preserving semantics.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16239#pullrequestreview-1685991329

From vklang at openjdk.org  Thu Oct 19 09:31:10 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Oct 2023 09:31:10 GMT
Subject: RFR: 8318420 : AbstractPipeline invokes overridden method in
 constructor
In-Reply-To: 
References: 
Message-ID: <_xFRExfrJka6See1MsjgS5C96s3wh1tLbgA4xOfl2QE=.b35e02d6-aac6-41fd-b5b7-7e5f1a0ad775@github.com>

On Wed, 18 Oct 2023 09:45:53 GMT, Viktor Klang  wrote:

> This PR corrects so that `opIsStateful()` is not invoked as a part of the java.util.stream.AbstractPipeline constructor?as `opIsStateful()` is intended to be overridden by subclasses, and as their own constructors have not run when their superclass constructor runs, this means that `opIsStateful()` cannot base its return value on any class members of the subclass.
> 
> Since `opIsStateful()` is only needed for parallel streams, we can therefor defer the invocation of `opIsStateful()` until evaluation-time, and as such we can remove the need for having an instance field to store the result of the invocation?making Stream instances potentially a tiny bit smaller, reducing Stream-construction overhead, while still preserving semantics.

@PaulSandoz Would you be up for reviewing this one? :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16239#issuecomment-1768085268

From mcimadamore at openjdk.org  Thu Oct 19 09:43:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Oct 2023 09:43:37 GMT
Subject: RFR: 8318454: TestLayoutPaths broken on Big Endian platforms after
 JDK-8317837
In-Reply-To: 
References: 
Message-ID: 

On Thu, 19 Oct 2023 06:18:18 GMT, Per Minborg  wrote:

> This PR suggests a fix for a failing test on platforms with big endian.
> 
> The PR also contains a drive-by removal of an unused import.

@TheRealMDoerr can you please check this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16259#issuecomment-1770446083

From mdoerr at openjdk.org  Thu Oct 19 09:53:39 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 19 Oct 2023 09:53:39 GMT
Subject: RFR: 8318454: TestLayoutPaths broken on Big Endian platforms after
 JDK-8317837
In-Reply-To: 
References: 
Message-ID: 

On Thu, 19 Oct 2023 06:18:18 GMT, Per Minborg  wrote:

> This PR suggests a fix for a failing test on platforms with big endian.
> 
> The PR also contains a drive-by removal of an unused import.

Test has passed. Thanks for fixing this so quickly!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16259#pullrequestreview-1687229939

From mcimadamore at openjdk.org  Thu Oct 19 09:53:40 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Oct 2023 09:53:40 GMT
Subject: RFR: 8318454: TestLayoutPaths broken on Big Endian platforms after
 JDK-8317837
In-Reply-To: 
References: 
Message-ID: 

On Thu, 19 Oct 2023 06:18:18 GMT, Per Minborg  wrote:

> This PR suggests a fix for a failing test on platforms with big endian.
> 
> The PR also contains a drive-by removal of an unused import.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16259#pullrequestreview-1687230461

From mcimadamore at openjdk.org  Thu Oct 19 09:53:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Oct 2023 09:53:49 GMT
Subject: Integrated: 8318324: Drop redundant default methods from FFM API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 17:31:30 GMT, Maurizio Cimadamore  wrote:

> This PR moves turns default methods in `MemorySegment` and `MemoryLayout` into ordinary abstract methods.
> These interfaces cannot be subclasses by developers (they are sealed), so there is no reson for having default methods there. Also, default methods can have some detrimental effects, as they cause the interfaces to be initialized more eagerly.

This pull request has now been integrated.

Changeset: 15acf4b8
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9
Stats:     634 lines in 4 files changed: 357 ins; 227 del; 50 mod

8318324: Drop redundant default methods from FFM API

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/16224

From vklang at openjdk.org  Thu Oct 19 10:13:37 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 19 Oct 2023 10:13:37 GMT
Subject: RFR: 8318420 : AbstractPipeline invokes overridden method in
 constructor
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 Oct 2023 09:45:53 GMT, Viktor Klang  wrote:

> This PR corrects so that `opIsStateful()` is not invoked as a part of the java.util.stream.AbstractPipeline constructor?as `opIsStateful()` is intended to be overridden by subclasses, and as their own constructors have not run when their superclass constructor runs, this means that `opIsStateful()` cannot base its return value on any class members of the subclass.
> 
> Since `opIsStateful()` is only needed for parallel streams, we can therefor defer the invocation of `opIsStateful()` until evaluation-time, and as such we can remove the need for having an instance field to store the result of the invocation?making Stream instances potentially a tiny bit smaller, reducing Stream-construction overhead, while still preserving semantics.

Pre-submit test seems unrelated to PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16239#issuecomment-1770498282

From mchung at openjdk.org  Thu Oct 19 10:15:41 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 19 Oct 2023 10:15:41 GMT
Subject: RFR: 8317634: Introduce the ability to exclude modules from
 dedup-legal-notices plugin of jlink [v3]
In-Reply-To: 
References: 
 
Message-ID: <0qPfNteXA8QRrcTU_Ac4HOmEu7jZHsy1R_XF3D3z6TI=.0f075603-7362-490a-b765-b6edc55b079e@github.com>

On Fri, 6 Oct 2023 02:22:52 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/JDK-8317634?
>> 
>> The change in this commit introduces a new `exclude-modules` argument to the `dedup-legal-notices` jlink plugin. This optional argument takes a comma separated values of module names. These module names are then excluded from the de-duplication of license notice files during image generation.
>> 
>> (Edited to add some context) The motivation for this change is discussed here https://github.com/openjdk/jdk/pull/13686#issuecomment-1747301865
>> 
>> Two new test methods have been added to the existing `LegalFilePluginTest` jtreg test case to verify this implementation. Existing tests in `test/jdk/tools/jlink` continue to pass. tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes to the text in plugin.properties for the new argument, to render better on command line

Unfortunately this does not fully solve JDK-8306980.   These legal files are part of the javadoc output (via `javadoc --legal-notices` option).   Same problem still exists if running on a custom image without a copy of these javadoc legal files.

I think the right solution should be for javadoc to keep these files from its resources directory like all other files such as `*.js` so that the proper version of these legal files are copied to the javadoc output directory.    It should not depend on the jlink output as the content might be transformed by jlink plugins.

I also added a comment in #13686.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16066#issuecomment-1770501386

From rgiulietti at openjdk.org  Thu Oct 19 10:24:45 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 19 Oct 2023 10:24:45 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
Message-ID: <0H6aE9gGK6DYTLUiCslROSDHzE6g8jduLBUm5m3JUls=.2b6e64c5-1fd5-416f-9a48-b113dfbea09f@github.com>

On Wed, 18 Oct 2023 15:59:31 GMT, Claes Redestad  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use StringConcatFactory.makeConcatWithConstants
>
> I've opened up #16244 for review - thanks for helping with analysis and verification.

@cl4es @wenshao I'd like to review the mathematical aspects of these changes once the refactorings with string concatenations have stabilized enough to your satisfaction.

Please ping me here when no more such work is planned.
TIA

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1770517453

From pminborg at openjdk.org  Thu Oct 19 10:50:50 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Oct 2023 10:50:50 GMT
Subject: Integrated: 8318454: TestLayoutPaths broken on Big Endian platforms
 after JDK-8317837
In-Reply-To: 
References: 
Message-ID: 

On Thu, 19 Oct 2023 06:18:18 GMT, Per Minborg  wrote:

> This PR suggests a fix for a failing test on platforms with big endian.
> 
> The PR also contains a drive-by removal of an unused import.

This pull request has now been integrated.

Changeset: defc7e0f
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/defc7e0f8d32e2dc62568f34d86d8f77a759e6ce
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8318454: TestLayoutPaths broken on Big Endian platforms after JDK-8317837

Reviewed-by: mdoerr, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/16259

From jpai at openjdk.org  Thu Oct 19 11:08:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 19 Oct 2023 11:08:51 GMT
Subject: RFR: 8317634: Introduce the ability to exclude modules from
 dedup-legal-notices plugin of jlink [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 02:22:52 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/JDK-8317634?
>> 
>> The change in this commit introduces a new `exclude-modules` argument to the `dedup-legal-notices` jlink plugin. This optional argument takes a comma separated values of module names. These module names are then excluded from the de-duplication of license notice files during image generation.
>> 
>> (Edited to add some context) The motivation for this change is discussed here https://github.com/openjdk/jdk/pull/13686#issuecomment-1747301865
>> 
>> Two new test methods have been added to the existing `LegalFilePluginTest` jtreg test case to verify this implementation. Existing tests in `test/jdk/tools/jlink` continue to pass. tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor changes to the text in plugin.properties for the new argument, to render better on command line

Thank you for that input Mandy. Given that this enhancement was requested specifically for trying to solve the javadoc generation issue in https://github.com/openjdk/jdk/pull/13686 and since this doesn't solve it, I'll go ahead and close this enhancement request.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16066#issuecomment-1770587347

From jpai at openjdk.org  Thu Oct 19 11:08:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 19 Oct 2023 11:08:52 GMT
Subject: Withdrawn: 8317634: Introduce the ability to exclude modules from
 dedup-legal-notices plugin of jlink
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 01:39:29 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/JDK-8317634?
> 
> The change in this commit introduces a new `exclude-modules` argument to the `dedup-legal-notices` jlink plugin. This optional argument takes a comma separated values of module names. These module names are then excluded from the de-duplication of license notice files during image generation.
> 
> (Edited to add some context) The motivation for this change is discussed here https://github.com/openjdk/jdk/pull/13686#issuecomment-1747301865
> 
> Two new test methods have been added to the existing `LegalFilePluginTest` jtreg test case to verify this implementation. Existing tests in `test/jdk/tools/jlink` continue to pass. tier testing is currently in progress.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16066

From duke at openjdk.org  Thu Oct 19 11:19:46 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 19 Oct 2023 11:19:46 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
Message-ID: 

On Thu, 28 Sep 2023 15:01:25 GMT, Raffaello Giulietti  wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> Meaningful external reviews take a _lot_ of engineering time on such a popular platform as the JDK.
> They make sense only on somehow stable code, otherwise they are a waste of human resources.
> 
> So sure, take your time to stabilize your code, make your tests, but please refrain from keep on changing too much once you publish a PR. If reviewers have to face continuous changes, they might become uninterested in reviewing.

Thanks to @rgiulietti for the review, I have changed the FormatProcessor according to your suggestion and added test cases

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1770659922

From duke at openjdk.org  Thu Oct 19 11:41:47 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 19 Oct 2023 11:41:47 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
Message-ID: 

On Wed, 18 Oct 2023 15:59:31 GMT, Claes Redestad  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use StringConcatFactory.makeConcatWithConstants
>
> I've opened up #16244 for review - thanks for helping with analysis and verification.

@cl4es 

> Good, narrows it down to what's going on in `prepend(long, byte[], String)`. Might boil down to `System.arraycopy`. This method might not be optimized for tiny arrays on all platforms. Specializing for single-char case:
> 
> ```java
> diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
> index 9b19d7e2ac1..6eb70925dab 100644
> --- a/src/java.base/share/classes/java/lang/String.java
> +++ b/src/java.base/share/classes/java/lang/String.java
> @@ -4723,7 +4723,11 @@ static void repeatCopyRest(byte[] buffer, int offset, int limit, int copied) {
>       */
>      void getBytes(byte[] dst, int dstBegin, byte coder) {
>          if (coder() == coder) {
> -            System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
> +            if (value.length == 1) {
> +                dst[(dstBegin << coder)] = value[0];
> +            } else {
> +                System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
> +            }
>          } else {    // this.coder == LATIN && coder == UTF16
>              StringLatin1.inflate(value, 0, dst, dstBegin, value.length);
>          }
> ```
> 
> .. seem to help the JIT do the right thing consistently, too:
> 
> ```
> Benchmark                                 Mode  Cnt   Score   Error  Units
> BigDecimals.testSmallToEngineeringString  avgt   50  11,757 ? 0,480  ns/op
> ```

In addition to #16244, will you submit a PR for this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1770715334

From redestad at openjdk.org  Thu Oct 19 11:43:29 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Oct 2023 11:43:29 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions [v2]
In-Reply-To: 
References: 
Message-ID: 

> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - dropLookupMode PRIVATE to ensure we don't accidentally use private methods
 - Make all prepend methods package-private

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16244/files
  - new: https://git.openjdk.org/jdk/pull/16244/files/4e7dfc0f..faa823d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16244&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16244&range=00-01

  Stats: 10 lines in 1 file changed: 2 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16244/head:pull/16244

PR: https://git.openjdk.org/jdk/pull/16244

From liach at openjdk.org  Thu Oct 19 11:43:30 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Oct 2023 11:43:30 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions [v2]
In-Reply-To: 
References: 
 
Message-ID: <8Rc2nvE10XHSpLaaF7fzdWd4KFeZGDpmGQpDYzKMDj4=.bd4278f1-26bc-4363-ac54-0156ed835509@github.com>

On Thu, 19 Oct 2023 11:39:24 GMT, Claes Redestad  wrote:

>> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - dropLookupMode PRIVATE to ensure we don't accidentally use private methods
>  - Make all prepend methods package-private

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16244#pullrequestreview-1687451479

From redestad at openjdk.org  Thu Oct 19 11:43:34 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Oct 2023 11:43:34 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 02:16:03 GMT, Chen Liang  wrote:

>> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - dropLookupMode PRIVATE to ensure we don't accidentally use private methods
>>  - Make all prepend methods package-private
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 725:
> 
>> 723:     }
>> 724: 
>> 725:     private static MethodHandle noPrefixPrepender(Class cl) {
> 
> Should the no-prefix prependers be declared package-private now that they are accessed via JLA? Otherwise we might accidentally change those APIs and break stuff.
> 
> Another way to guard is to make stringConcatHelper find methods with a lookup restricted to package access by changing this line: https://github.com/openjdk/jdk/blob/e25a49a993f270c33f7929e629fb3075a11fdec9/src/java.base/share/classes/java/lang/StringConcatHelper.java#L589
> to
> 
> return MethodHandles.lookup()
>         .dropLookupMode(MethodHandles.Lookup.PRIVATE)
>         .findStatic(StringConcatHelper.class, name, methodType);

Good points, adjusted accordingly. Will rerun tier1+2 testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16244#discussion_r1365364910

From mchhipa at openjdk.org  Thu Oct 19 11:43:57 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 19 Oct 2023 11:43:57 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed
 [v12]
In-Reply-To: 
References: 
Message-ID: 

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Added indentation to generate the properly indented code.
  Revert back to Formatter class from HexFormat class, so that Any Java version serialization code
  can be generated.
  Added "Mechanically generated" notation to already generated classes with Old Java versions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/2512e026..e2c4880e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=10-11

  Stats: 36 lines in 6 files changed: 12 ins; 2 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From redestad at openjdk.org  Thu Oct 19 12:00:54 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Oct 2023 12:00:54 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
 
Message-ID: 

On Thu, 19 Oct 2023 11:38:57 GMT, Shaojin Wen  wrote:

> In addition to #16244, will you submit a PR for this?

Once both #16244 and this has been integrated I want to revisit this. The effect of changing `getBytes(byte[], int, byte)` might have disappeared with #16244 since it better guarantees the JIT will constant fold the prefixes thoroughly. We've observed related issues with System.arraycopy, however, see https://bugs.openjdk.org/browse/JDK-8295496 - so I want to evaluate a few different options here, time allowing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1770752234

From mchhipa at openjdk.org  Thu Oct 19 12:02:46 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Thu, 19 Oct 2023 12:02:46 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed
 [v11]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 14:55:13 GMT, Roger Riggs  wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Corrected use of whitespace in text block.
>
> test/jdk/javax/xml/jaxp/datatype/8033980/GregorianCalAndDurSerDataUtil.java line 127:
> 
>> 125:         HexFormat hex = HexFormat.of().withPrefix(" (byte) 0x").withSuffix(",");
>> 126:         for (int i = 0; i < bytes.length; i += linelen) {
>> 127:             sb.append("\n");
> 
> Add some indentation before each line so the resulting code is properly indented.

Added the indentation, reverted back to the use of Formatter class instead of HexFormat class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1365396006

From igavrilin at openjdk.org  Thu Oct 19 12:14:52 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Thu, 19 Oct 2023 12:14:52 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
> 
> Tests:
> Performance tests on t-head board:
> With intrinsics:
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
> 
> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
> 
> Regression tests: tier1, hotspot:tier2 on risc-v board.
> 
> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
> 
> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> index 6cd1353907e..0bee25366bf 100644
> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>  
>      @Benchmark
>      public double  copySignDouble() {
> -        return  Math.copySign(double81, doubleNegative12);
> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>      }
>  
>      @Benchmark
>      public float  copySignFloat() {
> -        return  Math.copySign(floatNegative99, float1);
> +        return  Math.copySign(floatNegative99, float1) + Math.copySign(eFloat, float1) + Math.copySign...

Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:

  Changed branch inside signum implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16186/files
  - new: https://git.openjdk.org/jdk/pull/16186/files/c0a2ab95..867d6e8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=02-03

  Stats: 10 lines in 1 file changed: 3 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16186/head:pull/16186

PR: https://git.openjdk.org/jdk/pull/16186

From vkempik at openjdk.org  Thu Oct 19 12:20:41 2023
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Thu, 19 Oct 2023 12:20:41 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 12:14:52 GMT, Ilya Gavrilin  wrote:

>> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
>> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
>> 
>> Tests:
>> Performance tests on t-head board:
>> With intrinsics:
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
>> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
>> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
>> 
>> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
>> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
>> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
>> 
>> Regression tests: tier1, hotspot:tier2 on risc-v board.
>> 
>> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
>> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
>> 
>> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> index 6cd1353907e..0bee25366bf 100644
>> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>>  
>>      @Benchmark
>>      public double  copySignDouble() {
>> -        return  Math.copySign(double81, doubleNegative12);
>> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>>      }
>>  
>>      @Benchmark
>>      public float  copySignFloat() {
>> -        return  Math.copySign(floatNegative99, float1);
>> +        return  ...
>
> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed branch inside signum implementation

Looks good, last change is pretty similar to what was done here https://github.com/openjdk/jdk/pull/13800/commits/00e16a6726c258ad1409c7c671b9742bf8448a55

-------------

Marked as reviewed by vkempik (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16186#pullrequestreview-1687538633

From igavrilin at openjdk.org  Thu Oct 19 12:20:42 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Thu, 19 Oct 2023 12:20:42 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 12:14:52 GMT, Ilya Gavrilin  wrote:

>> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
>> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
>> 
>> Tests:
>> Performance tests on t-head board:
>> With intrinsics:
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
>> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
>> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
>> 
>> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
>> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
>> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
>> 
>> Regression tests: tier1, hotspot:tier2 on risc-v board.
>> 
>> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
>> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
>> 
>> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> index 6cd1353907e..0bee25366bf 100644
>> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>>  
>>      @Benchmark
>>      public double  copySignDouble() {
>> -        return  Math.copySign(double81, doubleNegative12);
>> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>>      }
>>  
>>      @Benchmark
>>      public float  copySignFloat() {
>> -        return  Math.copySign(floatNegative99, float1);
>> +        return  ...
>
> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed branch inside signum implementation

Change branch inside `signum`, now `dst` always moves to `src`, so we can remove `j(done); `
Performance results:
Without intrinsic:

Benchmark               (seed)   Mode  Cnt      Score    Error   Units
MathBench.signumDouble       0  thrpt    8  35666.674 ?  6.317  ops/ms
MathBench.signumFloat        0  thrpt    8  34040.220 ? 13.783  ops/ms

With old version:

Benchmark               (seed)   Mode  Cnt      Score    Error   Units
MathBench.signumDouble       0  thrpt    8  41601.513 ? 16.570  ops/ms
MathBench.signumFloat        0  thrpt    8  39414.511 ? 28.290  ops/ms

With new version:

Benchmark               (seed)   Mode  Cnt      Score    Error   Units
MathBench.signumDouble       0  thrpt    8  44060.456 ? 12.483  ops/ms
MathBench.signumFloat        0  thrpt    8  40481.776 ? 28.512  ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16186#issuecomment-1770835814

From fyang at openjdk.org  Thu Oct 19 12:25:41 2023
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 19 Oct 2023 12:25:41 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 12:14:52 GMT, Ilya Gavrilin  wrote:

>> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
>> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
>> 
>> Tests:
>> Performance tests on t-head board:
>> With intrinsics:
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
>> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
>> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
>> 
>> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
>> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
>> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
>> 
>> Regression tests: tier1, hotspot:tier2 on risc-v board.
>> 
>> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
>> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
>> 
>> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> index 6cd1353907e..0bee25366bf 100644
>> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>>  
>>      @Benchmark
>>      public double  copySignDouble() {
>> -        return  Math.copySign(double81, doubleNegative12);
>> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>>      }
>>  
>>      @Benchmark
>>      public float  copySignFloat() {
>> -        return  Math.copySign(floatNegative99, float1);
>> +        return  ...
>
> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed branch inside signum implementation

Still good. You might want to correct the remaining typo.

src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1660:

> 1658: // otherwise return +/- 1.0 using sign of input.
> 1659: // one - gives us a floating-point 1.0 (got from matching rule)
> 1660: // bool is_double - specififes single or double precision operations will be used.

Suggestion: s/specififes/specifies/

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16186#pullrequestreview-1687549814
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1365427533

From igavrilin at openjdk.org  Thu Oct 19 12:35:19 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Thu, 19 Oct 2023 12:35:19 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v5]
In-Reply-To: 
References: 
Message-ID: 

> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
> 
> Tests:
> Performance tests on t-head board:
> With intrinsics:
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
> 
> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
> 
> Regression tests: tier1, hotspot:tier2 on risc-v board.
> 
> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
> 
> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> index 6cd1353907e..0bee25366bf 100644
> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>  
>      @Benchmark
>      public double  copySignDouble() {
> -        return  Math.copySign(double81, doubleNegative12);
> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>      }
>  
>      @Benchmark
>      public float  copySignFloat() {
> -        return  Math.copySign(floatNegative99, float1);
> +        return  Math.copySign(floatNegative99, float1) + Math.copySign(eFloat, float1) + Math.copySign...

Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in c2 MacroAssembler

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16186/files
  - new: https://git.openjdk.org/jdk/pull/16186/files/867d6e8e..c79fb9e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16186/head:pull/16186

PR: https://git.openjdk.org/jdk/pull/16186

From igavrilin at openjdk.org  Thu Oct 19 12:35:19 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Thu, 19 Oct 2023 12:35:19 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 19 Oct 2023 12:22:29 GMT, Fei Yang  wrote:

> Still good. You might want to correct the remaining typo.

Thanks for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16186#issuecomment-1770876188

From mdoerr at openjdk.org  Thu Oct 19 13:01:45 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 19 Oct 2023 13:01:45 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v5]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 18 Oct 2023 14:47:58 GMT, Jorn Vernee  wrote:

> > I wonder if the native_invoker_size_per_arg thing still works good enough. We may exceed the computed size, now, right?
> 
> Good point. I'll have a look at enhancing the test we have for this.
> 
> Intuitively, I think it will be okay. It's true that we generate more code to add the oops and offsets together, but at the same time, we don't have any code to shuffle the offsets.

Looks like we use 2 input regs per obj, so we reserve 2x native_invoker_size_per_arg. However, the case in which `reg_oop` and `reg_offset` are on stack together with `arg_shuffle` can produce more than this size (depending on platform). If we pass lots of objects on stack, we may exceed the computed size. Correct?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1770938705

From duke at openjdk.org  Thu Oct 19 13:06:23 2023
From: duke at openjdk.org (yaqsun)
Date: Thu, 19 Oct 2023 13:06:23 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27 [v4]
In-Reply-To: 
References: 
Message-ID: 

> on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
> It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
> But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.

yaqsun has updated the pull request incrementally with one additional commit since the last revision:

  generate a temporary patch to trigger the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15832/files
  - new: https://git.openjdk.org/jdk/pull/15832/files/f853fb13..fb39c4cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15832&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15832&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15832/head:pull/15832

PR: https://git.openjdk.org/jdk/pull/15832

From sgehwolf at redhat.com  Thu Oct 19 13:12:55 2023
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Oct 2023 15:12:55 +0200
Subject: RFC: CSR review for run-image-based jlink
Message-ID: 

Hi,

Could I please get some reviews on the CSR for a feature that would
allow runtime image-based jlinks (no need for the packaged modules -
jmods folder - being present)?

https://bugs.openjdk.org/browse/JDK-8317420

It would be particularly helpful to get consensus on the naming (it's
hard!) and basic workflow. If there is any information missing, please
let me know.

Thank you!

Cheers,
Severin


From sgehwolf at openjdk.org  Thu Oct 19 13:23:43 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 19 Oct 2023 13:23:43 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v6]
In-Reply-To: 
References: 
 
Message-ID: <0ACw3XuOGq8JV9-wZzvqT1WbOPdZPKxDxV9UycGB0cw=.1a0b6cca-9214-47b5-875a-f43bc6851455@github.com>

On Wed, 18 Oct 2023 17:37:30 GMT, Severin Gehwolf  wrote:

>> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.j...
>
> Severin Gehwolf has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add a message when a run-image based link is being performed
>  - Add hint to the modified file case
>  - AddJmodResourcesPlugin => AddRunImageResourcesPlugin rename
>  - --add-jmod-resources => --add-run-image-resources rename
>    
>    Also rename jmod_resources to runimage_resources

Current GHA failure of `gc/TestJNICriticalStressTest#id0` on Windows seems unrelated. FWIW, [this check](https://github.com/jerboaa/jdk/actions/runs/6564461520) which also includes jlink tests passed fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1770977417

From liach at openjdk.org  Thu Oct 19 13:26:49 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 19 Oct 2023 13:26:49 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 28 Jun 2023 07:02:17 GMT, Chen Liang  wrote:

>> Summaries:
>> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
>> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
>> 3. Most tests are included in tier1, but some are not:
>> In `:jdk_io`: (tier2, part 2)
>> 
>> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
>> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
>> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
>> 
>> In `:jdk_instrument`: (tier 3)
>> 
>> test/jdk/java/lang/instrument/RetransformAgent.java
>> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
>> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
>> 
>> 
>> @asotona Would you mind reviewing?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Classfile object update
>  - Merge branch 'master' into invoke-test-classfile
>  - Merge branch 'master' into invoke-test-classfile
>  - Switch to ConstantDescs for   and void constants
>  - Merge AnnotationsTest, remove ModuleTargetAttribute call
>  - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
>  - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - Merge branch 'master' into invoke-test-classfile
>  - Fix LambdaStackTrace after running
>  - formatting
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/526dba1a...d0b6c2ae

Keeping alive, I plan to return to this patch after the integration of Class-File API transition to preview.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1770982707

From Alan.Bateman at oracle.com  Thu Oct 19 13:27:33 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Oct 2023 14:27:33 +0100
Subject: RFC: CSR review for run-image-based jlink
In-Reply-To: 
References: 
Message-ID: 

On 19/10/2023 14:12, Severin Gehwolf wrote:
> Hi,
>
> Could I please get some reviews on the CSR for a feature that would
> allow runtime image-based jlinks (no need for the packaged modules -
> jmods folder - being present)?
>
> https://bugs.openjdk.org/browse/JDK-8317420
>
> It would be particularly helpful to get consensus on the naming (it's
> hard!) and basic workflow. If there is any information missing, please
> let me know.
>

I plan to come back to the PR and our discussion when I can find time. 
There are several aspects to this overall proposal that I think will go 
through a few more iterations. I think TBD if jlink options will be 
exposed or whether it just complicates the picture.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pminborg at openjdk.org  Thu Oct 19 13:36:01 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 19 Oct 2023 13:36:01 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v10]
In-Reply-To: 
References: 
Message-ID: <3dl3aEeGly12k8ym7G5lK7utYvR9Imq6z9p13Hfshqw=.676beaa9-8bcb-457d-ab25-7f6b229d13fc@github.com>

> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
> 
> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
> 
> We need to benchmark this solution to better understand its implications.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove caching in TreeMap

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15614/files
  - new: https://git.openjdk.org/jdk/pull/15614/files/949dee26..9efc1bae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=08-09

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15614/head:pull/15614

PR: https://git.openjdk.org/jdk/pull/15614

From sgehwolf at redhat.com  Thu Oct 19 13:44:13 2023
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Oct 2023 15:44:13 +0200
Subject: RFC: CSR review for run-image-based jlink
In-Reply-To: 
References: 
 
Message-ID: <8441294c8da8ba65821f40b52df77b1932d29442.camel@redhat.com>

On Thu, 2023-10-19 at 14:27 +0100, Alan Bateman wrote:
> > Could I please get some reviews on the CSR for a feature that would
> > allow runtime image-based jlinks (no need for the packaged modules -
> > jmods folder - being present)?
> > 
> > https://bugs.openjdk.org/browse/JDK-8317420
> > 
> > It would be particularly helpful to get consensus on the naming (it's
> > hard!) and basic workflow. If there is any information missing, please
> > let me know.
> > 
> ?
> 
> I plan to come back to the PR and our discussion when I can find
> time. There are several aspects to this overall proposal that I think
> will go through a few more iterations. I think TBD if jlink options
> will be exposed or whether it just complicates the picture.

Thanks, Alan. I appreciate that and it's understood.

The reason why I wanted to post a reference to the CSR to this list was
to get broader awareness of this and perhaps get the one or the other
additional feedback that hasn't popped up yet. I believe this could
happen in parallel and the CSR explains how such a feature could
(potentially) work without looking at the code at all.

Thanks,
Severin


From lucy at openjdk.org  Thu Oct 19 13:46:46 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 19 Oct 2023 13:46:46 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 17:38:24 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add s390 support

See inline comments for s390 part.
I didn't review all the other code.

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 100:

> 98:       Address offset_addr(callerSP, FP_BIAS + reg_offset.offset());
> 99:       __ mem2reg_opt(r_tmp1, offset_addr, true);
> 100:       __ z_agr(reg_oop_reg, r_tmp1);

Please note that s390 is a CISC architecture. It provides instructions for almost everything. :-)
Here, I would suggest to add the offset to reg_oop_reg directly from memory - without first loading the offset into a temp register (that is RISC style). It's shorter and faster:
`  __ z_ag(reg_oop_reg, offset_addr);`

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 112:

> 110:     __ mem2reg_opt(r_tmp2, oop_addr, true);
> 111:     __ z_agr(r_tmp1, r_tmp2);
> 112:     __ reg2mem_opt(r_tmp1, oop_addr, true);

Similar to above. You need to load only one operand into a register.

  __ mem2reg_opt(r_tmp2, oop_addr, true);
  __ z_ag(r_tmp2, offset_addr);
  __ reg2mem_opt(r_tmp2, oop_addr, true);

-------------

Changes requested by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16201#pullrequestreview-1687765628
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1365554460
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1365560688

From fjiang at openjdk.org  Thu Oct 19 13:46:46 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Thu, 19 Oct 2023 13:46:46 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 17:38:24 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add s390 support

Here is the patch for risc-v: [riscv_panama_heap_segments.patch](https://github.com/openjdk/jdk/files/13043332/riscv_panama_heap_segments.patch)

All `jdk_foreign` tests passed on linux-riscv with `-XX+VerifyOops -XX:+VerifyStack` and fastdebug build.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1771014968

From lucy at openjdk.org  Thu Oct 19 13:46:48 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 19 Oct 2023 13:46:48 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 18 Oct 2023 17:04:52 GMT, Sidraya Jayagond  wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add PPC impl
>>  - add missing file
>
> Add s390x port from here
> [S390x_Panama_heap_segments.txt](https://github.com/openjdk/jdk/files/13031418/S390x_Panama_heap_segments.txt)
> 
> All tests are passing on linux S390x. One single test case is failing on Big Endian:
> test TestLayoutPaths.testBadAlignmentOfRoot(): failure. Similar to PPC Big Endian.

@sid8606 You may want to have a look at my s390 comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1771020553

From lkorinth at openjdk.org  Thu Oct 19 15:16:13 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 19 Oct 2023 15:16:13 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v5]
In-Reply-To: 
References: 
Message-ID: 

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * 
 Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      *  and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Batch update using sed
   
   find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
   find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
   find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"
 - Merge branch '_master_jdk' into _8315097
 - explain usage
 - Revert "8315097: Rename createJavaProcessBuilder"
   
   This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
 - Revert "copyright"
   
   This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
 - Revert "fix static import"
   
   This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.
 - fix static import
 - copyright
 - 8315097: Rename createJavaProcessBuilder

-------------

Changes: https://git.openjdk.org/jdk/pull/15452/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=04
  Stats: 894 lines in 560 files changed: 34 ins; 10 del; 850 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

PR: https://git.openjdk.org/jdk/pull/15452

From lkorinth at openjdk.org  Thu Oct 19 15:16:42 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 19 Oct 2023 15:16:42 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v4]
In-Reply-To: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>
References: 
 <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>
Message-ID: <3XTw5IAFj_YpaMrqyLdO9mNbWDENFMVkwk8JBmKHDcE=.5e4b1c70-0b36-4ff5-9cce-ee4f25a8e3bb@github.com>

On Tue, 17 Oct 2023 12:29:46 GMT, Leo Korinth  wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * 
 Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      *  and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "8315097: Rename createJavaProcessBuilder"
>    
>    This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
>  - Revert "copyright"
>    
>    This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
>  - Revert "fix static import"
>    
>    This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.

If this looks roughly acceptable, I will manually add indentation spaces. I am now running tests.

The changes can be verified by running the following commands:

git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9 

find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"

git diff HEAD f80dda8d7109c2ef6bc1f685d0b611704dec645e


Only the documentation changes should be visible.  When I have manually indented everything it should be easy to that verify that change as a whitespace-only change. But that is for tomorrow (at best).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1771194189

From ccheung at openjdk.org  Thu Oct 19 15:21:55 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 19 Oct 2023 15:21:55 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  simplify some code in modules.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16016/files
  - new: https://git.openjdk.org/jdk/pull/16016/files/ad4a58d8..471f6414

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=01-02

  Stats: 16 lines in 1 file changed: 5 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16016/head:pull/16016

PR: https://git.openjdk.org/jdk/pull/16016

From jvernee at openjdk.org  Thu Oct 19 15:28:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 19 Oct 2023 15:28:54 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v8]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:

 - add stub size stress test for allowHeap
 - RISC-V impl
 - remove leftover debug log line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/65bd8d83..dd9e9741

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=06-07

  Stats: 151 lines in 4 files changed: 74 ins; 66 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From jvernee at openjdk.org  Thu Oct 19 15:28:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 19 Oct 2023 15:28:57 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 19 Oct 2023 13:40:55 GMT, Feilong Jiang  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add s390 support
>
> Here is the patch for risc-v: [riscv_panama_heap_segments.patch](https://github.com/openjdk/jdk/files/13043332/riscv_panama_heap_segments.patch)
> 
> All `jdk_foreign` tests passed on linux-riscv with `-XX+VerifyOops -XX:+VerifyStack` and fastdebug build.

@feilongjiang Thanks, I've added it to the PR

@TheRealMDoerr Note that `reg_offset` is filtered out, and not handled by `arg_shuffle`. So, it becomes the question whether shuffling a register, or adding an offset to an oop takes more bytes. I think most of the `native_invoker_size_per_arg` have some lenience built in though? (I did do that for x64 and aarch64 at least). So, I think it will be okay.

I've added an additional test case to the existing test for this, which should stress the new code gen. (https://github.com/openjdk/jdk/pull/16201/commits/dd9e9741de3ca07e6a4cc561002255f98e1e3330)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1771209486

From redestad at openjdk.org  Thu Oct 19 15:59:54 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Oct 2023 15:59:54 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions [v3]
In-Reply-To: 
References: 
Message-ID: <9sWtCh2cq-I6AW3vA9uPY_bR_4ClWBzR03NljKw1ir8=.c5a3653b-84fc-4291-8b0d-9f05d5d91919@github.com>

> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  drop dropLookupMode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16244/files
  - new: https://git.openjdk.org/jdk/pull/16244/files/faa823d3..ca0ac91f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16244&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16244&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16244/head:pull/16244

PR: https://git.openjdk.org/jdk/pull/16244

From redestad at openjdk.org  Thu Oct 19 16:08:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 19 Oct 2023 16:08:42 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions [v3]
In-Reply-To: <9sWtCh2cq-I6AW3vA9uPY_bR_4ClWBzR03NljKw1ir8=.c5a3653b-84fc-4291-8b0d-9f05d5d91919@github.com>
References: 
 <9sWtCh2cq-I6AW3vA9uPY_bR_4ClWBzR03NljKw1ir8=.c5a3653b-84fc-4291-8b0d-9f05d5d91919@github.com>
Message-ID: <37z0si-_8Ew1ch0Hb7T_d8yh3_6D8TE4sK8V638pWng=.a1b9e219-15be-48a5-9d17-ad63a6a206a5@github.com>

On Thu, 19 Oct 2023 15:59:54 GMT, Claes Redestad  wrote:

>> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop dropLookupMode

Using dropLookupMode caused a bootstrap cycle in tests where a SecurityManager is installed, causing lots of test failures. Reverting that part.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16244#issuecomment-1771296318

From mli at openjdk.org  Thu Oct 19 16:10:24 2023
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 19 Oct 2023 16:10:24 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 17:35:58 GMT, Ilya Gavrilin  wrote:

>> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
>> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
>> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
>> 
>> Tests:
>> Performance tests on t-head board:
>> With intrinsics:
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
>> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
>> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
>> 
>> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
>> 
>> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
>> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
>> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
>> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
>> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
>> 
>> Regression tests: tier1, hotspot:tier2 on risc-v board.
>> 
>> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
>> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
>> 
>> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> index 6cd1353907e..0bee25366bf 100644
>> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
>> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>>  
>>      @Benchmark
>>      public double  copySignDouble() {
>> -        return  Math.copySign(double81, doubleNegative12);
>> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>>      }
>>  
>>      @Benchmark
>>      public float  copySignFloat() {
>> -        return  Math.copySign(floatNegative99, float1);
>> +        return  ...
>
> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove some effects and assert

src/hotspot/cpu/riscv/riscv.ad line 7520:

> 7518:     __ fsgnj_d(dst, src1, src2);
> 7519:   %}
> 7520:   ins_pipe(fp_uop_d);

Should ins_pipe be `fp_dop_reg_reg_d` here?

src/hotspot/cpu/riscv/riscv.ad line 7532:

> 7530:     __ fsgnj_s(dst, src1, src2);
> 7531:   %}
> 7532:   ins_pipe(fp_uop_d);

Should ins_pipe be `fp_dop_reg_reg_s` here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1364312642
PR Review Comment: https://git.openjdk.org/jdk/pull/16186#discussion_r1364313031

From mcimadamore at openjdk.org  Thu Oct 19 17:46:17 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Oct 2023 17:46:17 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout
In-Reply-To: 
References: 
 
Message-ID: <8CUOUPGxuQn_6e-KkIccpAmPT4fUdUcEIuu0Mk3uWMY=.3192d026-9a0b-4348-9601-c71bc42d4e31@github.com>

On Wed, 18 Oct 2023 23:56:17 GMT, Maurizio Cimadamore  wrote:

>> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
>
> src/java.desktop/share/classes/sun/font/HBShaper.java line 110:
> 
>> 108: 
>> 109:     private static VarHandle getVarHandle(StructLayout struct, String name) {
>> 110:         VarHandle h = struct.varHandle(PathElement.groupElement(name));
> 
> Note that, strictly speaking, these combiners are _not_ required. If you just call `MemoryLayout::varHandle`, you get back a var handle that takes a `MemorySegment` and a `long` offset. So, you can, if you want, adapt the var handle so that the offset parameter becomes something else. But you could also just leave the var handle as is. Then, in the loop that is doing the access, you can do this:
> 
> 
> for (int i = 0 ; i < limit ; i++) {
>    x_offsetHandle.get(segment, PositionLayout.scale(0, i));
>    y_offsetHandle.get(segment, PositionLayout.scale(0, i));
>    ...
> }
> 
> That is, use the offset hole to your advantage, to pass the struct base offset (obtained by scaling the enclosing struct layout by the value of the loop induction variable).
> 
> (That said, I understand that working with logical indices is a common operation, and that this is made a bit harder by the recent API changes. We should consider, as @JornVernee mentioned, adding back a more general `MemoryLayout::arrayElementVarHandle` which will give you the var handle you need - with coordinates `MemorySegment` and `long` - a logical index, not an offset).

A PR which adds `MemoryLayout::arrayElementVarHandle` can be found here:
https://github.com/openjdk/jdk/pull/16272

With this, you can call the new method in order to create the var handle. The returned var handle will accept *two* long coordinate - the first is a base offset (as usual), the second in a logical index (what you need). The PR also adds plenty of narrative text describing how access to variable-length arrays should be performed using layouts (and also shows cases where the offset parameter is used in a non-trivial fashion).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1365898029

From sjayagond at openjdk.org  Thu Oct 19 18:00:42 2023
From: sjayagond at openjdk.org (Sidraya Jayagond)
Date: Thu, 19 Oct 2023 18:00:42 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 19 Oct 2023 15:21:02 GMT, Jorn Vernee  wrote:

>> Here is the patch for risc-v: [riscv_panama_heap_segments.patch](https://github.com/openjdk/jdk/files/13043332/riscv_panama_heap_segments.patch)
>> 
>> All `jdk_foreign` tests passed on linux-riscv with `-XX+VerifyOops -XX:+VerifyStack` and fastdebug build.
>
> @feilongjiang Thanks, I've added it to the PR
> 
> @TheRealMDoerr Note that `reg_offset` is filtered out, and not handled by `arg_shuffle`. So, it becomes the question whether shuffling a register, or adding an offset to an oop takes more bytes. I think most of the `native_invoker_size_per_arg` have some lenience built in though? (I did do that for x64 and aarch64 at least). So, I think it will be okay.
> 
> I've added an additional test case to the existing test for this, which should stress the new code gen. (https://github.com/openjdk/jdk/pull/16201/commits/dd9e9741de3ca07e6a4cc561002255f98e1e3330)

@JornVernee please add this patch which addresses @RealLucy comments. 
[0001-Address-Lutz-Schmidt-s-review-comments.txt](https://github.com/openjdk/jdk/files/13046011/0001-Address-Lutz-Schmidt-s-review-comments.txt)
Also tested additional test case on s390x that @JornVernee have added and I see it is passing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1771454607

From sjayagond at openjdk.org  Thu Oct 19 18:00:59 2023
From: sjayagond at openjdk.org (Sidraya Jayagond)
Date: Thu, 19 Oct 2023 18:00:59 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 19 Oct 2023 13:37:09 GMT, Lutz Schmidt  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add s390 support
>
> src/hotspot/cpu/s390/downcallLinker_s390.cpp line 100:
> 
>> 98:       Address offset_addr(callerSP, FP_BIAS + reg_offset.offset());
>> 99:       __ mem2reg_opt(r_tmp1, offset_addr, true);
>> 100:       __ z_agr(reg_oop_reg, r_tmp1);
> 
> Please note that s390 is a CISC architecture. It provides instructions for almost everything. :-)
> Here, I would suggest to add the offset to reg_oop_reg directly from memory - without first loading the offset into a temp register (that is RISC style). It's shorter and faster:
> `  __ z_ag(reg_oop_reg, offset_addr);`

That's right @RealLucy. Thanks for reviewing.

> src/hotspot/cpu/s390/downcallLinker_s390.cpp line 112:
> 
>> 110:     __ mem2reg_opt(r_tmp2, oop_addr, true);
>> 111:     __ z_agr(r_tmp1, r_tmp2);
>> 112:     __ reg2mem_opt(r_tmp1, oop_addr, true);
> 
> Similar to above. You need to load only one operand into a register.
> 
>   __ mem2reg_opt(r_tmp2, oop_addr, true);
>   __ z_ag(r_tmp2, offset_addr);
>   __ reg2mem_opt(r_tmp2, oop_addr, true);

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1365916526
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1365916660

From sjayagond at openjdk.org  Thu Oct 19 18:18:22 2023
From: sjayagond at openjdk.org (Sidraya Jayagond)
Date: Thu, 19 Oct 2023 18:18:22 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: <6YFCmKEmndViMxqdZTi0Jl-CvAz3LGJ-Et6bOnCqGVg=.7678f793-9c66-4d76-96f5-6b791e3172be@github.com>

On Thu, 19 Oct 2023 15:21:02 GMT, Jorn Vernee  wrote:

>> Here is the patch for risc-v: [riscv_panama_heap_segments.patch](https://github.com/openjdk/jdk/files/13043332/riscv_panama_heap_segments.patch)
>> 
>> All `jdk_foreign` tests passed on linux-riscv with `-XX+VerifyOops -XX:+VerifyStack` and fastdebug build.
>
> @feilongjiang Thanks, I've added it to the PR
> 
> @TheRealMDoerr Note that `reg_offset` is filtered out, and not handled by `arg_shuffle`. So, it becomes the question whether shuffling a register, or adding an offset to an oop takes more bytes. I think most of the `native_invoker_size_per_arg` have some lenience built in though? (I did do that for x64 and aarch64 at least). So, I think it will be okay.
> 
> I've added an additional test case to the existing test for this, which should stress the new code gen. (https://github.com/openjdk/jdk/pull/16201/commits/dd9e9741de3ca07e6a4cc561002255f98e1e3330)

@JornVernee  Please add below patch for addressing of @RealLucy review comments.
[0001-Address-Lutz-Schmidt-s-review-comments.txt](https://github.com/openjdk/jdk/files/13046224/0001-Address-Lutz-Schmidt-s-review-comments.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1771488927

From mcimadamore at openjdk.org  Thu Oct 19 18:26:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Oct 2023 18:26:12 GMT
Subject: RFR: 8318538: Add a way to obtain a strided var handle from a layout
Message-ID: 

The 21 iteration of the FFM API used to contain a method, namely `ValueLayout::arrayElementVarHandle`. This var handle factory was useful when accessing elements in a flat array of variable size.

In 22, this method has been removed because:
* It was not general enough (it only worked with value layouts)
* A more useful/general version could be obtained with the following code:


MethodHandles.collectCoordinates(varHandle(elements), 1, scaleHandle());


Given that accessing variable-length array is rather common, and given that combining var handles is perceived as hard, we noticed that developers often tried to workaround by creating a sequence layout of maximal size, and then deriving a var handle from it. This feels suboptimal (as a new layout is created just so that we can select from it, and using this layout for anything else will likely lead to exceptions, because of its size).

For these reasons, we would like to expose this functionality as a new method in the `MemoryLayout` interface, namely `MemoryLayout::arrayElementVarHandle`. This method generalizes the old method in the 21 API, and is implemented in the obvious way, using a combinator (see above).

This PR also adds a lot of narrative text to describe how to deal with variable-length arrays, which should clarify the role of the new method.

-------------

Commit messages:
 - Inital push

Changes: https://git.openjdk.org/jdk/pull/16272/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16272&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318538
  Stats: 163 lines in 6 files changed: 119 ins; 20 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16272.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16272/head:pull/16272

PR: https://git.openjdk.org/jdk/pull/16272

From ccheung at openjdk.org  Thu Oct 19 18:26:55 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 19 Oct 2023 18:26:55 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <1_6r5eykghxdWHC48f3ojn4EDswUhayzEc_c3eLhf04=.7fec5352-d0c2-4533-a76c-c770f84cbec0@github.com>

On Thu, 5 Oct 2023 16:23:03 GMT, Ioi Lam  wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify some code in modules.cpp
>
> src/hotspot/share/classfile/modules.cpp line 597:
> 
>> 595:         MetaspaceShared::disable_optimized_module_handling();
>> 596:       }
>> 597:     }
> 
> I think this code can be made less verbose: 
> 
>     bool disable = false;
>     if (runtime_main_module == nullptr) {
>       if (_archived_main_module_name != nullptr) {
>         log_info(cds)("Module %s specified during dump time but not during runtime", _archived_main_module_name);
>         disable = true;
>       }
>     } else {
>       if (_archived_main_module_name == nullptr) {
>         log_info(cds)("Module %s specified during runtime but not during dump time", runtime_main_module);
>         disable = true;
>       } else if (strcmp(runtime_main_module, _archived_main_module_name) != 0) {
>         log_info(cds)("Mismatched modules: runtime %s dump time %s", runtime_main_module, _archived_main_module_name);
>         disable = true;
>       }
>     }
> 
>     if (disable) {
>       log_info(cds)("Disabling optimized module handling");
>       MetaspaceShared::disable_optimized_module_handling();
>     }

I've pushed a commit with the above simplification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1365948448

From jlu at openjdk.org  Thu Oct 19 18:30:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Oct 2023 18:30:31 GMT
Subject: Integrated: 8318322: Update IANA Language Subtag Registry to Version
 2023-10-16
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu  wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

This pull request has now been integrated.

Changeset: cc8f8da2
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/cc8f8da293914c25cb15d38caad994bc761a3957
Stats:     53 lines in 2 files changed: 50 ins; 0 del; 3 mod

8318322: Update IANA Language Subtag Registry to Version 2023-10-16

Reviewed-by: naoto, iris, lancea, srl

-------------

PR: https://git.openjdk.org/jdk/pull/16227

From jvernee at openjdk.org  Thu Oct 19 18:58:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 19 Oct 2023 18:58:09 GMT
Subject: RFR: 8318538: Add a way to obtain a strided var handle from a
 layout
In-Reply-To: 
References: 
Message-ID: <2fhbSlzjaXDP8HSIKaR-VuB0Tpu8Zmzg2jnYLyxVYOA=.7884eb68-063e-4618-b28f-0613cfc977eb@github.com>

On Thu, 19 Oct 2023 16:52:53 GMT, Maurizio Cimadamore  wrote:

> The 21 iteration of the FFM API used to contain a method, namely `ValueLayout::arrayElementVarHandle`. This var handle factory was useful when accessing elements in a flat array of variable size.
> 
> In 22, this method has been removed because:
> * It was not general enough (it only worked with value layouts)
> * A more useful/general version could be obtained with the following code:
> 
> 
> MethodHandles.collectCoordinates(varHandle(elements), 1, scaleHandle());
> 
> 
> Given that accessing variable-length array is rather common, and given that combining var handles is perceived as hard, we noticed that developers often tried to workaround by creating a sequence layout of maximal size, and then deriving a var handle from it. This feels suboptimal (as a new layout is created just so that we can select from it, and using this layout for anything else will likely lead to exceptions, because of its size).
> 
> For these reasons, we would like to expose this functionality as a new method in the `MemoryLayout` interface, namely `MemoryLayout::arrayElementVarHandle`. This method generalizes the old method in the 21 API, and is implemented in the obvious way, using a combinator (see above).
> 
> This PR also adds a lot of narrative text to describe how to deal with variable-length arrays, which should clarify the role of the new method.

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 334:

> 332:  * }
> 333:  *
> 334:  * Here, the coordinate {@code x} of subsequent point in the array are accessed using the {@code POINT_ARR_X} var

Suggestion:

 * Here, the coordinate {@code x} of subsequent points in the array is accessed using the {@code POINT_ARR_X} var

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 137:

> 135:  *
> 136:  * {@snippet lang=java:
> 137:  * MethodHandle scale = ValueLayout.JAVA_INT.scaleHandle();

`scale` seems unused now

-------------

PR Review: https://git.openjdk.org/jdk/pull/16272#pullrequestreview-1688419431
PR Review Comment: https://git.openjdk.org/jdk/pull/16272#discussion_r1365965777
PR Review Comment: https://git.openjdk.org/jdk/pull/16272#discussion_r1365981020

From dalibor.topic at oracle.com  Thu Oct 19 21:35:49 2023
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Thu, 19 Oct 2023 23:35:49 +0200
Subject: Request for JCK17 tests exclusion
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

Hi Ramdas,

On a side note, please do not forward or copy e-mails from the 
conformance-octla-private mailing list to other OpenJDK mailing lists, 
since they may contain confidential information.

Instead, please start a fresh thread in the future describing the 
specific concerns with specific functionality in the OpenJDK source code.

cheers,
dalibor topic

On 18.10.2023 19:47, Nandagiri, Ramadasu (NSDi) wrote:
> Hi Alan,
> 
> Thanks for your response and the suggestion. I have copied, net-dev on 
> my original mail. I will wait for a response from net-dev group.
> 
> Regards,
> Ramdas
> ------------------------------------------------------------------------
> *From:* Alan Bateman 
> *Sent:* Wednesday, October 18, 2023 8:51 PM
> *To:* Nandagiri, Ramadasu (NSDi) ; 
> net-dev at openjdk.org ; core-libs-dev at openjdk.org 
> 
> *Cc:* Bhat, Suma Mudakare Bheema (NSDi) ; Gragg, 
> Jeffrey 
> *Subject:* Re: Request for JCK17 tests exclusion
> On 18/10/2023 15:55, Nandagiri, Ramadasu (NSDi) wrote:
>> Hi,
>>
>> Please see the discussion in the following mails. One of the TCK test 
>> cases, api/java_net/MulticastSocket/ClassLevel.html is failing on 
>> NonStop platform as NonStop doesn't support?IP_MULTICAST_ALL option.
>>
>> We would like this test case to be excluded from TCK. Please share 
>> your thoughts on this request.
> 
> I realize you have been directed here but this is not the right place to 
> discuss TCK exclusion requests.
> 
>  From the mails you forwarded then it looks like there are issues with 
> the multicast support in your port to NonStop. The IP_MULTICAST_ALL 
> socket option you mention is used in the Linux port to avoid 
> interference when two sockets are bound to the same port but joined to 
> different multicast groups. Linux is an outlier in this scenario so the 
> socket option is set to prevent the interference. My guess is that few 
> people here will know NonStop but you could being porting questions on 
> this code to net-dev.
> 
> -Alan

-- 
 Dalibor Topic
Consulting Product Manager
Phone: +494089091214 , Mobile: +491737185961


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From jlu at openjdk.org  Thu Oct 19 21:44:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Oct 2023 21:44:33 GMT
Subject: RFR: JDK-7061097: [Doc] Inconsistenency between the spec and the
 implementation for DateFormat.Field
Message-ID: 

Please review this PR which adjusts the specification of `DateFormat.Field::getCalendarField` to conform to the implementation.

`getCalendarField()` claims that it will return -1 if there is no corresponding `Calendar` constant.

Although the built-in DateFormat.Fields with no associated `Calendar` constant are created with a `calendarField` equal to -1, a subclass can create a DateFormat.Field with no associated `Calendar` constant with `calendarField` equal to anything.

The specification of `getCalendarField()` should be adjusted to reflect this. That is, a separate implementation may or may not return -1 if there is no associated `Calendar` constant.

-------------

Commit messages:
 - this implementation -> the default implementation
 - init

Changes: https://git.openjdk.org/jdk/pull/16279/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16279&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7061097
  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16279/head:pull/16279

PR: https://git.openjdk.org/jdk/pull/16279

From mdoerr at openjdk.org  Thu Oct 19 21:54:57 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 19 Oct 2023 21:54:57 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v5]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <8hx8KP0ZWoairTjroq63c1XF9AChGkNeayW_83uIUAM=.90edba42-261c-4192-ba1a-9ce3eddb9004@github.com>

On Thu, 19 Oct 2023 12:58:39 GMT, Martin Doerr  wrote:

>>> I wonder if the native_invoker_size_per_arg thing still works good enough. We may exceed the computed size, now, right?
>> 
>> Good point. I'll have a look at enhancing the test we have for this. 
>> 
>> Intuitively, I think it will be okay. It's true that we generate more code to add the oops and offsets together, but at the same time, we don't have any code to shuffle the offsets.
>
>> > I wonder if the native_invoker_size_per_arg thing still works good enough. We may exceed the computed size, now, right?
>> 
>> Good point. I'll have a look at enhancing the test we have for this.
>> 
>> Intuitively, I think it will be okay. It's true that we generate more code to add the oops and offsets together, but at the same time, we don't have any code to shuffle the offsets.
> 
> Looks like we use 2 input regs per obj, so we reserve 2x native_invoker_size_per_arg. However, the case in which `reg_oop` and `reg_offset` are on stack together with `arg_shuffle` can produce more than this size (depending on platform). If we pass lots of objects on stack, we may exceed the computed size. Correct?

> @TheRealMDoerr Note that `reg_offset` is filtered out, and not handled by `arg_shuffle`. So, it becomes the question whether shuffling a register, or adding an offset to an oop takes more bytes. I think most of the `native_invoker_size_per_arg` have some lenience built in though? (I did do that for x64 and aarch64 at least). So, I think it will be okay.

Right.
The filtering happens after the size computation `code_size = native_invoker_code_base_size + (num_args * native_invoker_size_per_arg)`, so we reserve 2 * native_invoker_size_per_arg per heap segment which is 2 * 2 instructions on PPC64.
The maximum actual code size is the size of the 1 * add_offset operation + 1 arg shuffle, which is 4 + 2 instructions on PPC64.
So, we reserve space for 4 instructions, but emit 6 ones.
The reason why it still works is that `_needs_transition` must be false and that saves more space than we exceeded by the oversized argument handling code.
Not a very nice design, but I can live with it.
 
> I've added an additional test case to the existing test for this, which should stress the new code gen. ([dd9e974](https://github.com/openjdk/jdk/commit/dd9e9741de3ca07e6a4cc561002255f98e1e3330))

Thanks for adding it! Would you mind using `limit(84)` which is the maximum? We'd be on the safe side when testing this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1771757690

From mcimadamore at openjdk.org  Thu Oct 19 20:49:13 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 19 Oct 2023 20:49:13 GMT
Subject: RFR: 8318538: Add a way to obtain a strided var handle from a
 layout [v2]
In-Reply-To: 
References: 
Message-ID: 

> The 21 iteration of the FFM API used to contain a method, namely `ValueLayout::arrayElementVarHandle`. This var handle factory was useful when accessing elements in a flat array of variable size.
> 
> In 22, this method has been removed because:
> * It was not general enough (it only worked with value layouts)
> * A more useful/general version could be obtained with the following code:
> 
> 
> MethodHandles.collectCoordinates(varHandle(elements), 1, scaleHandle());
> 
> 
> Given that accessing variable-length array is rather common, and given that combining var handles is perceived as hard, we noticed that developers often tried to workaround by creating a sequence layout of maximal size, and then deriving a var handle from it. This feels suboptimal (as a new layout is created just so that we can select from it, and using this layout for anything else will likely lead to exceptions, because of its size).
> 
> For these reasons, we would like to expose this functionality as a new method in the `MemoryLayout` interface, namely `MemoryLayout::arrayElementVarHandle`. This method generalizes the old method in the 21 API, and is implemented in the obvious way, using a combinator (see above).
> 
> This PR also adds a lot of narrative text to describe how to deal with variable-length arrays, which should clarify the role of the new method.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16272/files
  - new: https://git.openjdk.org/jdk/pull/16272/files/31934027..ee6c3579

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16272&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16272&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16272.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16272/head:pull/16272

PR: https://git.openjdk.org/jdk/pull/16272

From mdoerr at openjdk.org  Thu Oct 19 22:24:45 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 19 Oct 2023 22:24:45 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 15:28:54 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - add stub size stress test for allowHeap
>  - RISC-V impl
>  - remove leftover debug log line

This is probably the wrong place to ask this, but the sizing topic leads me to another issue: `RuntimeStub::new_runtime_stub` can return `nullptr` when the code cache is full and we would crash when trying to call `nullptr->print_on(&ls)`. Also, what will the Java code do when `downcallStubAddress` is 0 in the `NativeEntryPoint`?
Do you want me to file an issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1771784660

From jlu at openjdk.org  Thu Oct 19 22:55:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Oct 2023 22:55:42 GMT
Subject: Integrated: JDK-8315064: j.text.ChoiceFormat provides no specification
 on quoting behavior
In-Reply-To: 
References: 
Message-ID: 

On Fri, 29 Sep 2023 20:46:44 GMT, Justin Lu  wrote:

> Please review this PR and which adjusts the pattern section of java.text.ChoiceFormat to specify the single quote behavior within a String pattern.
> 
> The other Format classes that take a String pattern such as DecimalFormat, CompactNumberFormat, and MessageFormat all provide specification on single quote behavior within a String pattern. ChoiceFormat should have similar specification.

This pull request has now been integrated.

Changeset: 684b91ef
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/684b91efbb22f16cd0952283e8c960846c39d1db
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8315064: j.text.ChoiceFormat provides no specification on quoting behavior

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15994

From naoto at openjdk.org  Thu Oct 19 23:01:27 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 19 Oct 2023 23:01:27 GMT
Subject: RFR: JDK-7061097: [Doc] Inconsistenency between the spec and the
 implementation for DateFormat.Field
In-Reply-To: 
References: 
Message-ID: 

On Thu, 19 Oct 2023 21:31:13 GMT, Justin Lu  wrote:

> Please review this PR which adjusts the specification of `DateFormat.Field::getCalendarField` to conform to the implementation.
> 
> `getCalendarField()` claims that it will return -1 if there is no corresponding `Calendar` constant.
> 
> Although the built-in DateFormat.Fields with no associated `Calendar` constant are created with a `calendarField` equal to -1, a subclass can create a DateFormat.Field with no associated `Calendar` constant with `calendarField` equal to anything.
> 
> The specification of `getCalendarField()` should be adjusted to reflect this. That is, a separate implementation may or may not return -1 if there is no associated `Calendar` constant.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16279#pullrequestreview-1688819904

From duke at openjdk.org  Thu Oct 19 23:21:09 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 19 Oct 2023 23:21:09 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v9]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: 

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove JLA

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/89cad442..a17a106c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=07-08

  Stats: 26 lines in 1 file changed: 10 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From duke at openjdk.org  Fri Oct 20 01:04:45 2023
From: duke at openjdk.org (yaqsun)
Date: Fri, 20 Oct 2023 01:04:45 GMT
Subject: RFR: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27 [v5]
In-Reply-To: 
References: 
Message-ID: 

> on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
> It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
> But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.

yaqsun has updated the pull request incrementally with one additional commit since the last revision:

  After tests passed, restore the temporary patch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15832/files
  - new: https://git.openjdk.org/jdk/pull/15832/files/fb39c4cc..d30af0ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15832&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15832&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15832/head:pull/15832

PR: https://git.openjdk.org/jdk/pull/15832

From duke at openjdk.org  Fri Oct 20 01:39:55 2023
From: duke at openjdk.org (duke)
Date: Fri, 20 Oct 2023 01:39:55 GMT
Subject: Withdrawn: 8310843: Reimplement ByteArray and ByteArrayLittleEndian
 with Unsafe
In-Reply-To: 
References: 
Message-ID: 

On Sat, 24 Jun 2023 06:42:18 GMT, Glavo  wrote:

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14636

From iklam at openjdk.org  Fri Oct 20 02:28:27 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 20 Oct 2023 02:28:27 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 15:21:55 GMT, Calvin Cheung  wrote:

>> Please review this changeset for adding support for `--module` (-m) option for CDS.
>> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
>> 
>> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify some code in modules.cpp

The latest version looks good to me.

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16016#pullrequestreview-1689069318

From liach at openjdk.org  Fri Oct 20 02:29:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 02:29:15 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.xxNoRepl to xxReportError [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review a patch that renames `JavaLangAccess::newStringUTF8NoRepl` and `getBytesUTF8NoRepl` to `newStringUTF8FailFast` and `getBytesUTF8FailFast` to accurately describe these APIs. This also renames other associated methods.
> 
> NoRepl means "no replication", which is not what these APIs are for. They instead expose the fail-fast construction fast-path in String, allowing `ZipCoder` to quickly throw encoding exceptions wrapped in `IllegalArgumentException` without going through decoders and encoders.
> 
> In addition, there is already `newStringNoRepl` and `getBytesNoRepl` in `JavaLangAccess` that actually avoids copying arrays for trusted usages, further increasing the confusion. Given these internal APIs are frequently used in recent contributions around improving string performance, I believe a rename of these APIs is necessary.
> 
> Pinging @cl4es for a review since you use this particular API the most often.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  NoRepl -> ReportError

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16260/files
  - new: https://git.openjdk.org/jdk/pull/16260/files/1af50e96..3a94643c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16260&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16260&range=00-01

  Stats: 240 lines in 10 files changed: 95 ins; 96 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/16260.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16260/head:pull/16260

PR: https://git.openjdk.org/jdk/pull/16260

From liach at openjdk.org  Fri Oct 20 02:32:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 02:32:35 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.xxNoRepl to xxReportError [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 02:29:15 GMT, Chen Liang  wrote:

>> Please review a patch that renames `JavaLangAccess::xxNoRepl` to `xxReportError` to explicitly indicate these APIs report encoding errors.
>> 
>> The old "NoRepl" suffix presumably means "No Replacement", but it has been misunderstood as "No Replication" (#16209) and misused as an array sharing API in performance optimization patches.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NoRepl -> ReportError

I have decided to rename `NoRepl` to `ReportError`, as it corresponds to `CodingErrorAction.REPORT`. I have replaced all `NoRepl` occurrences I've found with `ReportError`, including in tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16260#issuecomment-1771979541

From almatvee at openjdk.org  Fri Oct 20 04:23:22 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 20 Oct 2023 04:23:22 GMT
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild [v3]
In-Reply-To: 
References: 
Message-ID: 

> - Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
> - If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
>> Error: "codesign" failed with following output:
>> test: no identity found
> 
>> Error: "productbuild" failed with following output:
>> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
> - Added error handling not to allow invalid combinations of signing options.
> - Updated signing tests to test new changes.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8311877: [macos] Add CLI options to provide signing identity directly to codesign and productbuild [v2]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16085/files
  - new: https://git.openjdk.org/jdk/pull/16085/files/4cd56e25..c3112444

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16085&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16085&range=01-02

  Stats: 159 lines in 9 files changed: 59 ins; 73 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/16085.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16085/head:pull/16085

PR: https://git.openjdk.org/jdk/pull/16085

From almatvee at openjdk.org  Fri Oct 20 04:26:38 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 20 Oct 2023 04:26:38 GMT
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 04:23:22 GMT, Alexander Matveev  wrote:

>> - Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
>> - If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
>>> Error: "codesign" failed with following output:
>>> test: no identity found
>> 
>>> Error: "productbuild" failed with following output:
>>> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
>> - Added error handling not to allow invalid combinations of signing options.
>> - Updated signing tests to test new changes.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311877: [macos] Add CLI options to provide signing identity directly to codesign and productbuild [v2]

Yes, you got it right. I agree it does not make sense to consider error if `--mac-sign` is not specified. I fixed it as you suggested. `--mac-app-image-sign-identity` will be ignored and no signing is done if `--mac-sign` is not specified.

Also, updated `SigningPackageTest.java` to include tests for cases when only app-image is being signed or when only pkg is being signed using sign identity options.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16085#issuecomment-1772057635

From liach at openjdk.org  Fri Oct 20 04:35:39 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 04:35:39 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 18:13:38 GMT, Glavo  wrote:

>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>> 
>> Reasons:
>> 
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
>> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.
>
> Glavo has updated the pull request with a new target base 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 branch 'openjdk:master' into latin1-no-repl
>  - Use newStringLatin1NoRepl in UUID
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - update javadoc
>  - clean newStringNoRepl1
>  - clean newStringNoRepl1
>  - Rename jla to JLA
>  - Create new method JavaLangAccess::newStringLatin1NoRepl

See [#16260](https://github.com/openjdk/jdk/pull/16260#issuecomment-1770217422): `NoRepl` means to report encoding error as CCE. The API you are creating should be renamed to something like `newTrustedLatin1String` as we don't check encoding errors and this API solely focuses on sharing the array.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1772064234

From liach at openjdk.org  Fri Oct 20 05:07:36 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 05:07:36 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions [v3]
In-Reply-To: <9sWtCh2cq-I6AW3vA9uPY_bR_4ClWBzR03NljKw1ir8=.c5a3653b-84fc-4291-8b0d-9f05d5d91919@github.com>
References: 
 <9sWtCh2cq-I6AW3vA9uPY_bR_4ClWBzR03NljKw1ir8=.c5a3653b-84fc-4291-8b0d-9f05d5d91919@github.com>
Message-ID: 

On Thu, 19 Oct 2023 15:59:54 GMT, Claes Redestad  wrote:

>> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop dropLookupMode

An alternative way to provide access control could be to call `MethodHandles.lookup()` in the anonymous `JavaLangAccess` implementation in `System`. This won't require an SM check as the lookup has full-privilege access, yet the lookup cannot access private members of `StringConcatHelper`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16244#issuecomment-1772087445

From pminborg at openjdk.org  Fri Oct 20 06:28:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 20 Oct 2023 06:28:35 GMT
Subject: RFR: 8318538: Add a way to obtain a strided var handle from a
 layout [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 20:49:13 GMT, Maurizio Cimadamore  wrote:

>> The 21 iteration of the FFM API used to contain a method, namely `ValueLayout::arrayElementVarHandle`. This var handle factory was useful when accessing elements in a flat array of variable size.
>> 
>> In 22, this method has been removed because:
>> * It was not general enough (it only worked with value layouts)
>> * A more useful/general version could be obtained with the following code:
>> 
>> 
>> MethodHandles.collectCoordinates(varHandle(elements), 1, scaleHandle());
>> 
>> 
>> Given that accessing variable-length array is rather common, and given that combining var handles is perceived as hard, we noticed that developers often tried to workaround by creating a sequence layout of maximal size, and then deriving a var handle from it. This feels suboptimal (as a new layout is created just so that we can select from it, and using this layout for anything else will likely lead to exceptions, because of its size).
>> 
>> For these reasons, we would like to expose this functionality as a new method in the `MemoryLayout` interface, namely `MemoryLayout::arrayElementVarHandle`. This method generalizes the old method in the 21 API, and is implemented in the obvious way, using a combinator (see above).
>> 
>> This PR also adds a lot of narrative text to describe how to deal with variable-length arrays, which should clarify the role of the new method.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by pminborg (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16272#pullrequestreview-1689323317

From liach at openjdk.org  Fri Oct 20 07:06:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 07:06:42 GMT
Subject: RFR: 8316587: Use ArraysSupport.vectorizedHashCode in
 Utf8EntryImpl [v2]
In-Reply-To: 
References: <3JSJ1HphYzBvczUUrmjZyhHLibVARKYgRJHv95VuiHc=.5374778f-a792-43bb-ac65-71b05d2906ab@github.com>
 
Message-ID: 

On Thu, 21 Sep 2023 02:38:08 GMT, Chen Liang  wrote:

>> Like #12077, this uses JDK's internal utilities to speed up ASCII reading in Class files, where most identifiers, from conventions to attribute names, are ASCII. See the JBS issue for more in-depth explanations.
>> 
>> Before: (Master)
>> 
>> Benchmark                         Mode  Cnt    Score   Error  Units
>> ReadMetadata.jdkReadMemberNames  thrpt    4  167.623 ? 8.522  ops/s
>> 
>> 
>> After: (This patch, first revision)
>> 
>> Benchmark                         Mode  Cnt    Score   Error  Units
>> ReadMetadata.jdkReadMemberNames  thrpt    4  175.908 ? 4.766  ops/s
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix logical bug with char array filling

Can anyone sponsor this patch? This should be compatible with Class-File transition to preview as this does not change any API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15837#issuecomment-1772195707

From jvernee at openjdk.org  Fri Oct 20 07:35:14 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Oct 2023 07:35:14 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v7]
In-Reply-To: <6YFCmKEmndViMxqdZTi0Jl-CvAz3LGJ-Et6bOnCqGVg=.7678f793-9c66-4d76-96f5-6b791e3172be@github.com>
References: 
 
 
 
 <6YFCmKEmndViMxqdZTi0Jl-CvAz3LGJ-Et6bOnCqGVg=.7678f793-9c66-4d76-96f5-6b791e3172be@github.com>
Message-ID: 

On Thu, 19 Oct 2023 18:15:45 GMT, Sidraya Jayagond  wrote:

>> @feilongjiang Thanks, I've added it to the PR
>> 
>> @TheRealMDoerr Note that `reg_offset` is filtered out, and not handled by `arg_shuffle`. So, it becomes the question whether shuffling a register, or adding an offset to an oop takes more bytes. I think most of the `native_invoker_size_per_arg` have some lenience built in though? (I did do that for x64 and aarch64 at least). So, I think it will be okay.
>> 
>> I've added an additional test case to the existing test for this, which should stress the new code gen. (https://github.com/openjdk/jdk/pull/16201/commits/dd9e9741de3ca07e6a4cc561002255f98e1e3330)
>
> @JornVernee  Please add below patch for addressing of @RealLucy review comments.
> [0001-Address-Lutz-Schmidt-s-review-comments.txt](https://github.com/openjdk/jdk/files/13046224/0001-Address-Lutz-Schmidt-s-review-comments.txt)

@sid8606 I've added the patch. There were a couple of commented out lines which I've removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1772229009

From jvernee at openjdk.org  Fri Oct 20 07:35:14 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Oct 2023 07:35:14 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v9]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  s390 updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/dd9e9741..5b7fc19e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=07-08

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From liach at openjdk.org  Fri Oct 20 07:39:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 07:39:45 GMT
Subject: Integrated: 8316587: Use ArraysSupport.vectorizedHashCode in
 Utf8EntryImpl
In-Reply-To: <3JSJ1HphYzBvczUUrmjZyhHLibVARKYgRJHv95VuiHc=.5374778f-a792-43bb-ac65-71b05d2906ab@github.com>
References: <3JSJ1HphYzBvczUUrmjZyhHLibVARKYgRJHv95VuiHc=.5374778f-a792-43bb-ac65-71b05d2906ab@github.com>
Message-ID: 

On Wed, 20 Sep 2023 09:17:24 GMT, Chen Liang  wrote:

> Like #12077, this uses JDK's internal utilities to speed up ASCII reading in Class files, where most identifiers, from conventions to attribute names, are ASCII. See the JBS issue for more in-depth explanations.
> 
> Before: (Master)
> 
> Benchmark                         Mode  Cnt    Score   Error  Units
> ReadMetadata.jdkReadMemberNames  thrpt    4  167.623 ? 8.522  ops/s
> 
> 
> After: (This patch, first revision)
> 
> Benchmark                         Mode  Cnt    Score   Error  Units
> ReadMetadata.jdkReadMemberNames  thrpt    4  175.908 ? 4.766  ops/s

This pull request has now been integrated.

Changeset: 4812caba
Author:    Chen Liang 
Committer: Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/4812cabaa489e99481facddce69686a9fee29c44
Stats:     48 lines in 2 files changed: 24 ins; 13 del; 11 mod

8316587: Use ArraysSupport.vectorizedHashCode in Utf8EntryImpl

Reviewed-by: asotona, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/15837

From jvernee at openjdk.org  Fri Oct 20 07:58:37 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Oct 2023 07:58:37 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 19 Oct 2023 22:21:33 GMT, Martin Doerr  wrote:

>> Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - add stub size stress test for allowHeap
>>  - RISC-V impl
>>  - remove leftover debug log line
>
> This is probably the wrong place to ask this, but the sizing topic leads me to another issue: `RuntimeStub::new_runtime_stub` can return `nullptr` when the code cache is full and we would crash when trying to call `nullptr->print_on(&ls)`. Also, what will the Java code do when `downcallStubAddress` is 0 in the `NativeEntryPoint`?
> Do you want me to file an issue?

@TheRealMDoerr 

> So, we reserve space for 4 instructions, but emit 6 ones.

We could bump up the size per arg.

I think I want to get a review for the rest of the hotspot changes first though, to avoid having to go through that process twice, in case changes to the code gen are needed.

> Would you mind using limit(84) which is the maximum?

Why is 84 the maximum? That would result in 170 Java parameters at most, which is well within the 255 limit imposed by the VM spec.

> `RuntimeStub::new_runtime_stub` can return `nullptr` when the code cache is full

As far as I can see we would hit a `fatal` error when the allocation of the runtime stub fails?

https://github.com/openjdk/jdk/blob/4812cabaa489e99481facddce69686a9fee29c44/src/hotspot/share/code/codeBlob.cpp#L425-L430

Note that `alloc_fail_is_fatal` is true by default, and we don't set it when calling `new_runtime_stub`.

Potentially we could bubble up this allocation failure as a Java exception (and do the same for upcall stubs). That would have the benefit of maybe only bringing down a single Java thread, but is at the same time not really a recoverable error, i.e. we can not just disable the linker, like we can for e.g. the JIT compiler. So I'm not sure if the fatal error is really that problematic. We should probably do the same for upcall stubs either way though. I've filed: https://bugs.openjdk.org/browse/JDK-8318586

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1772259563

From asotona at openjdk.org  Fri Oct 20 08:01:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 20 Oct 2023 08:01:57 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v22]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: 

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 353 commits:

 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - removed trailing space
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - package info javadoc improvements
 - removed obsolete exports from BuildMicrobenchmark.gmk
 - Merge branch 'master' into JDK-8308753-preview
 - added @sealedGraph tags
 - fixed exception type thrown from CodeImpl
 - added constraint to throw on an attempt to parse unknown classfile version
   + test
 - removed AttributeMapper::validSince
 - ... and 343 more: https://git.openjdk.org/jdk/compare/4812caba...9b77afb3

-------------

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=21
  Stats: 32121 lines in 764 files changed: 14618 ins; 14049 del; 3454 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From jvernee at openjdk.org  Fri Oct 20 08:02:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Oct 2023 08:02:46 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v8]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 20 Oct 2023 07:55:45 GMT, Jorn Vernee  wrote:

> Why is 84 the maximum? That would result in 170 Java parameters at most, which is well within the 255 limit imposed by the VM spec.

Ah, right, longs take up 2 slots. So, we get 84*3 = 252 + 4 (target address & return buffer) + 2 receiver method handle + NativeEntryPoint, which gives 258. Ok, I'll find out what the limit is and use that

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1772264403

From lkorinth at openjdk.org  Fri Oct 20 08:34:35 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 20 Oct 2023 08:34:35 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 15:16:13 GMT, Leo Korinth  wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * 
 Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      *  and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Batch update using sed
>    
>    find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
>    find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
>    find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"
>  - Merge branch '_master_jdk' into _8315097
>  - explain usage
>  - Revert "8315097: Rename createJavaProcessBuilder"
>    
>    This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
>  - Revert "copyright"
>    
>    This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
>  - Revert "fix static import"
>    
>    This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.
>  - fix static import
>  - copyright
>  - 8315097: Rename createJavaProcessBuilder

Just ignore what I just pushed, I will have a new version out

sorry...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309579
PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309992

From jvernee at openjdk.org  Fri Oct 20 08:38:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Oct 2023 08:38:22 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v10]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  bump up argument counts in TestLargeStub to their maximum

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/5b7fc19e..fef40cdb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=08-09

  Stats: 14 lines in 1 file changed: 8 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From ramadasu.nandagiri at hpe.com  Fri Oct 20 08:39:34 2023
From: ramadasu.nandagiri at hpe.com (Nandagiri, Ramadasu (NSDi))
Date: Fri, 20 Oct 2023 08:39:34 +0000
Subject: Request for JCK17 tests exclusion
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
 
 
 
Message-ID: 

Hi Dalibor,

Thank you for your suggestions. I have realized my mistake. I will discuss this further in JCK group and look for a conclusion.

Apologies for posting this topic here and wasting your time. Please consider this thread as closed.

Regards,
Ramdas

________________________________
From: core-libs-dev  on behalf of Dalibor Topic 
Sent: Friday, October 20, 2023 3:05 AM
To: core-libs-dev at openjdk.org 
Subject: Re: Request for JCK17 tests exclusion

Hi Ramdas,

On a side note, please do not forward or copy e-mails from the
conformance-octla-private mailing list to other OpenJDK mailing lists,
since they may contain confidential information.

Instead, please start a fresh thread in the future describing the
specific concerns with specific functionality in the OpenJDK source code.

cheers,
dalibor topic

On 18.10.2023 19:47, Nandagiri, Ramadasu (NSDi) wrote:
> Hi Alan,
>
> Thanks for your response and the suggestion. I have copied, net-dev on
> my original mail. I will wait for a response from net-dev group.
>
> Regards,
> Ramdas
> ------------------------------------------------------------------------
> *From:* Alan Bateman 
> *Sent:* Wednesday, October 18, 2023 8:51 PM
> *To:* Nandagiri, Ramadasu (NSDi) ;
> net-dev at openjdk.org ; core-libs-dev at openjdk.org
> 
> *Cc:* Bhat, Suma Mudakare Bheema (NSDi) ; Gragg,
> Jeffrey 
> *Subject:* Re: Request for JCK17 tests exclusion
> On 18/10/2023 15:55, Nandagiri, Ramadasu (NSDi) wrote:
>> Hi,
>>
>> Please see the discussion in the following mails. One of the TCK test
>> cases, api/java_net/MulticastSocket/ClassLevel.html is failing on
>> NonStop platform as NonStop doesn't support IP_MULTICAST_ALL option.
>>
>> We would like this test case to be excluded from TCK. Please share
>> your thoughts on this request.
>
> I realize you have been directed here but this is not the right place to
> discuss TCK exclusion requests.
>
>  From the mails you forwarded then it looks like there are issues with
> the multicast support in your port to NonStop. The IP_MULTICAST_ALL
> socket option you mention is used in the Linux port to avoid
> interference when two sockets are bound to the same port but joined to
> different multicast groups. Linux is an outlier in this scenario so the
> socket option is set to prevent the interference. My guess is that few
> people here will know NonStop but you could being porting questions on
> this code to net-dev.
>
> -Alan

--
 Dalibor Topic
Consulting Product Manager
Phone: +494089091214 , Mobile: +491737185961


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mdoerr at openjdk.org  Fri Oct 20 08:43:39 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 20 Oct 2023 08:43:39 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v8]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 20 Oct 2023 07:59:25 GMT, Jorn Vernee  wrote:

> > Why is 84 the maximum? That would result in 170 Java parameters at most, which is well within the 255 limit imposed by the VM spec.
> 
> Ah, right, longs take up 2 slots. So, we get 84*3 = 252 + 4 (target address & return buffer) + receiver method handle + NativeEntryPoint, which gives 258. Ok, I'll find out what the limit is and use that.
> 
> P.S. it's 83

Thanks! I should have mentioned that 84 is the limit for linux PPC64le. 83 should work for all platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1772321142

From rgiulietti at openjdk.org  Fri Oct 20 09:14:41 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 20 Oct 2023 09:14:41 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v3]
In-Reply-To: <2AUQJBYNCZaitrlfcUz1__tb_IEPw3BGfp1R8xmiMS0=.c2bf986d-2164-4931-b3f9-3d1f32cd345f@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 <2AUQJBYNCZaitrlfcUz1__tb_IEPw3BGfp1R8xmiMS0=.c2bf986d-2164-4931-b3f9-3d1f32cd345f@github.com>
Message-ID: 

On Thu, 19 Oct 2023 06:38:35 GMT, Shaojin Wen  wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix FormatterBuilder testcase handle lineSeparator on windows

src/java.base/share/classes/java/util/FormatProcessor.java line 247:

> 245:                 throw new MissingFormatArgumentException(group + " is not immediately followed by an embedded expression");
> 246:             } else {
> 247:                 throw new UnknownFormatConversionException(String.valueOf(c));

I don't think this exception is thrown by the original code.

src/java.base/share/classes/java/util/Formatter.java line 2889:

> 2887:         }
> 2888: 
> 2889:         int parse() {

Since the implementation of this method is far from trivial, it would be very useful to document what it returns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1366679352
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1366703609

From mcimadamore at openjdk.org  Fri Oct 20 10:26:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Oct 2023 10:26:53 GMT
Subject: RFR: 8317819: Scope should reflect lifetime of underying resource
 (mainline) [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR is based on a port of: openjdk/panama-foreign#898
> 
> Some additional changes are contained in this PR:
> 
> * instead of using a different "always alive" scope for zero-length memory segments, we now use the global scope
> * the javadoc for `MemorySegment::ofArray`, `MemorySegment::ofBuffer` and `SymbolLookup::loaderLookup` is tweaked to say that the scope associated to the returned segments is an automatic scope
> * the javadoc for `MemorySegment.Scope` defines the concepts of global and automatic scope, which are then referenced in the `Arena` javadoc.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Add newline at the end of test
 - Merge branch 'master' into better_scope_doc
 - Address review comments
 - Add test
 - Initial push

-------------

Changes: https://git.openjdk.org/jdk/pull/16183/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16183&range=03
  Stats: 269 lines in 12 files changed: 205 ins; 15 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/16183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16183/head:pull/16183

PR: https://git.openjdk.org/jdk/pull/16183

From mcimadamore at openjdk.org  Fri Oct 20 10:26:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Oct 2023 10:26:55 GMT
Subject: Integrated: 8317819: Scope should reflect lifetime of underying
 resource (mainline)
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 14:21:49 GMT, Maurizio Cimadamore  wrote:

> This PR is based on a port of: openjdk/panama-foreign#898
> 
> Some additional changes are contained in this PR:
> 
> * instead of using a different "always alive" scope for zero-length memory segments, we now use the global scope
> * the javadoc for `MemorySegment::ofArray`, `MemorySegment::ofBuffer` and `SymbolLookup::loaderLookup` is tweaked to say that the scope associated to the returned segments is an automatic scope
> * the javadoc for `MemorySegment.Scope` defines the concepts of global and automatic scope, which are then referenced in the `Arena` javadoc.

This pull request has now been integrated.

Changeset: b07da3ae
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/b07da3ae15dc820d596484d51d972404fed67fb1
Stats:     269 lines in 12 files changed: 205 ins; 15 del; 49 mod

8317819: Scope should reflect lifetime of underying resource (mainline)

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/16183

From mcimadamore at openjdk.org  Fri Oct 20 10:38:00 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Oct 2023 10:38:00 GMT
Subject: RFR: 8318538: Add a way to obtain a strided var handle from a
 layout [v3]
In-Reply-To: 
References: 
Message-ID: 

> The 21 iteration of the FFM API used to contain a method, namely `ValueLayout::arrayElementVarHandle`. This var handle factory was useful when accessing elements in a flat array of variable size.
> 
> In 22, this method has been removed because:
> * It was not general enough (it only worked with value layouts)
> * A more useful/general version could be obtained with the following code:
> 
> 
> MethodHandles.collectCoordinates(varHandle(elements), 1, scaleHandle());
> 
> 
> Given that accessing variable-length array is rather common, and given that combining var handles is perceived as hard, we noticed that developers often tried to workaround by creating a sequence layout of maximal size, and then deriving a var handle from it. This feels suboptimal (as a new layout is created just so that we can select from it, and using this layout for anything else will likely lead to exceptions, because of its size).
> 
> For these reasons, we would like to expose this functionality as a new method in the `MemoryLayout` interface, namely `MemoryLayout::arrayElementVarHandle`. This method generalizes the old method in the 21 API, and is implemented in the obvious way, using a combinator (see above).
> 
> This PR also adds a lot of narrative text to describe how to deal with variable-length arrays, which should clarify the role of the new method.

Maurizio Cimadamore has updated the pull request with a new target base 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 arrayElemVarHandle
 - Address review comments
 - Inital push

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16272/files
  - new: https://git.openjdk.org/jdk/pull/16272/files/ee6c3579..7d6659c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16272&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16272&range=01-02

  Stats: 2404 lines in 66 files changed: 1914 ins; 226 del; 264 mod
  Patch: https://git.openjdk.org/jdk/pull/16272.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16272/head:pull/16272

PR: https://git.openjdk.org/jdk/pull/16272

From mcimadamore at openjdk.org  Fri Oct 20 10:38:01 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Oct 2023 10:38:01 GMT
Subject: Integrated: 8318538: Add a way to obtain a strided var handle from a
 layout
In-Reply-To: 
References: 
Message-ID: 

On Thu, 19 Oct 2023 16:52:53 GMT, Maurizio Cimadamore  wrote:

> The 21 iteration of the FFM API used to contain a method, namely `ValueLayout::arrayElementVarHandle`. This var handle factory was useful when accessing elements in a flat array of variable size.
> 
> In 22, this method has been removed because:
> * It was not general enough (it only worked with value layouts)
> * A more useful/general version could be obtained with the following code:
> 
> 
> MethodHandles.collectCoordinates(varHandle(elements), 1, scaleHandle());
> 
> 
> Given that accessing variable-length array is rather common, and given that combining var handles is perceived as hard, we noticed that developers often tried to workaround by creating a sequence layout of maximal size, and then deriving a var handle from it. This feels suboptimal (as a new layout is created just so that we can select from it, and using this layout for anything else will likely lead to exceptions, because of its size).
> 
> For these reasons, we would like to expose this functionality as a new method in the `MemoryLayout` interface, namely `MemoryLayout::arrayElementVarHandle`. This method generalizes the old method in the 21 API, and is implemented in the obvious way, using a combinator (see above).
> 
> This PR also adds a lot of narrative text to describe how to deal with variable-length arrays, which should clarify the role of the new method.

This pull request has now been integrated.

Changeset: 848ecc16
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/848ecc1621c347ab12dd3f421af82cb55c71e075
Stats:     163 lines in 6 files changed: 119 ins; 21 del; 23 mod

8318538: Add a way to obtain a strided var handle from a layout

Reviewed-by: jvernee, pminborg

-------------

PR: https://git.openjdk.org/jdk/pull/16272

From duke at openjdk.org  Fri Oct 20 11:07:44 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 20 Oct 2023 11:07:44 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v3]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 <2AUQJBYNCZaitrlfcUz1__tb_IEPw3BGfp1R8xmiMS0=.c2bf986d-2164-4931-b3f9-3d1f32cd345f@github.com>
 
Message-ID: <6Vaf7kkwBnKX-wRwN-Oj4Mw7wwl5x0zq6e6u5FQDcH0=.ec0993d2-928f-4828-95e5-5a6fefdc8ce5@github.com>

On Fri, 20 Oct 2023 08:52:04 GMT, Raffaello Giulietti  wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix FormatterBuilder testcase handle lineSeparator on windows
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 247:
> 
>> 245:                 throw new MissingFormatArgumentException(group + " is not immediately followed by an embedded expression");
>> 246:             } else {
>> 247:                 throw new UnknownFormatConversionException(String.valueOf(c));
> 
> I don't think this exception is thrown by the original code.

I added these tests to show that the exceptions and messages thrown are the same as before.


// test/jdk/java/lang/template/FormatterBuilder.java
assertThrows(
        MissingFormatArgumentException.class,
        () -> fmt. "%10ba{ false }",
        "Format specifier '%10b is not immediately followed by an embedded expression'");

assertThrows(
        MissingFormatArgumentException.class,
        () ->fmt. "%ba{ false }",
        "Format specifier '%b is not immediately followed by an embedded expression'");

assertThrows(
        MissingFormatArgumentException.class,
        () ->fmt. "%b",
        "Format specifier '%b is not immediately followed by an embedded expression'");
assertThrows(
        UnknownFormatConversionException.class,
        () ->fmt. "%0",
        "Conversion = '0'");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1366829200

From redestad at openjdk.org  Fri Oct 20 11:22:31 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Oct 2023 11:22:31 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions [v3]
In-Reply-To: <9sWtCh2cq-I6AW3vA9uPY_bR_4ClWBzR03NljKw1ir8=.c5a3653b-84fc-4291-8b0d-9f05d5d91919@github.com>
References: 
 <9sWtCh2cq-I6AW3vA9uPY_bR_4ClWBzR03NljKw1ir8=.c5a3653b-84fc-4291-8b0d-9f05d5d91919@github.com>
Message-ID: 

On Thu, 19 Oct 2023 15:59:54 GMT, Claes Redestad  wrote:

>> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop dropLookupMode

I think we try to avoid having any additional logic in the `JavaLangAccess` type proxies. Either way I think this is getting out of scope for this PR and if there's a real need to lock down the mechanism it can be done in a follow-up. Do you agree?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16244#issuecomment-1772555820

From duke at openjdk.org  Fri Oct 20 11:37:54 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 20 Oct 2023 11:37:54 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v4]
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: <6wsvTQXwoavkZjonzYLmiMteWR8lCXLt-9k5TOYpAvU=.22153485-10ec-4748-9990-2cacfe585b82@github.com>

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add document

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/d8d3ef4b..abb90227

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=02-03

  Stats: 24 lines in 1 file changed: 22 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15776/head:pull/15776

PR: https://git.openjdk.org/jdk/pull/15776

From duke at openjdk.org  Fri Oct 20 11:38:40 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 20 Oct 2023 11:38:40 GMT
Subject: Withdrawn: 8318200: String::newStringNoRepl and String::getBytesNoRepl
 does not throw CharacterCodingException
In-Reply-To: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
References: <-kP43cf4VRF1BZS1LD6CDS4_VQf3nm-pW-OXelCNR9E=.4bfeb002-9f4b-4f0b-a0c0-f603d4da1cd7@github.com>
Message-ID: 

On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen  wrote:

> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use try...catch to handle CharacterCodingException and throw IllegalArgumentException instead of CharacterCodingException to make the calling code cleaner.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16209

From liach at openjdk.org  Fri Oct 20 11:39:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 20 Oct 2023 11:39:47 GMT
Subject: RFR: 8318457: Use prefix-less prepend methods directly to reduce
 branches in String concat expressions [v3]
In-Reply-To: <9sWtCh2cq-I6AW3vA9uPY_bR_4ClWBzR03NljKw1ir8=.c5a3653b-84fc-4291-8b0d-9f05d5d91919@github.com>
References: 
 <9sWtCh2cq-I6AW3vA9uPY_bR_4ClWBzR03NljKw1ir8=.c5a3653b-84fc-4291-8b0d-9f05d5d91919@github.com>
Message-ID: 

On Thu, 19 Oct 2023 15:59:54 GMT, Claes Redestad  wrote:

>> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop dropLookupMode

I strongly agree. SharedSecrets access implementations strive to be as concise as possible. We can always revisit the access control part.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16244#issuecomment-1772574121

From redestad at openjdk.org  Fri Oct 20 11:39:48 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 20 Oct 2023 11:39:48 GMT
Subject: Integrated: 8318457: Use prefix-less prepend methods directly to
 reduce branches in String concat expressions
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 Oct 2023 11:56:14 GMT, Claes Redestad  wrote:

> In #16006 using `StringConcatFactory` seem to induce a run-to-run variance. One idea to reduce this is to generate expression trees with fewer branches by looking up and using the prefix-less `prepend` methods directly for cases where constant is null/empty so that the prefixed prepender will always deal with a non-null prefix constant.

This pull request has now been integrated.

Changeset: fe529170
Author:    Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/fe52917054ebed3009391487c304f1fad4271049
Stats:     45 lines in 3 files changed: 15 ins; 10 del; 20 mod

8318457: Use prefix-less prepend methods directly to reduce branches in String concat expressions

Reviewed-by: jlaskey, liach

-------------

PR: https://git.openjdk.org/jdk/pull/16244

From duke at openjdk.org  Fri Oct 20 11:45:56 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 20 Oct 2023 11:45:56 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v10]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: <3xaSdgBtDs-rqztOMN6ipH7RQjt0CQZLuVdH8kSXFx0=.ff1445df-7a2a-480f-aa0a-e6eb584fcbc2@github.com>

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_decimal_to_string_x1
 - remove JLA
 - recipe ("\1.\1\1")
 - Use StringConcatFactory.makeConcatWithConstants
 - use % calculate lowInt
 - refactor based on @cl4es 's review
 - fix from @cl4es 's review
 - fix from @cl4es 's review
 - refactor based on @liach 's review
 - optimize BigDecimal.toString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/a17a106c..d5cbd7e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=08-09

  Stats: 35483 lines in 1139 files changed: 21247 ins; 7201 del; 7035 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From mchhipa at openjdk.org  Fri Oct 20 12:10:46 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 20 Oct 2023 12:10:46 GMT
Subject: Integrated: JDK-8077371: Binary files in JAXP test should be removed
In-Reply-To: 
References: 
Message-ID: 

On Wed, 19 Apr 2023 15:51:01 GMT, Mahendra Chhipa  wrote:

> Test is updated to create the binary files during test execution.

This pull request has now been integrated.

Changeset: 40106422
Author:    Mahendra Chhipa 
URL:       https://git.openjdk.org/jdk/commit/40106422bd2ae3da98d028bdbab2c240a71081e3
Stats:     928 lines in 16 files changed: 808 ins; 68 del; 52 mod

8077371: Binary files in JAXP test should be removed

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/13537

From igavrilin at openjdk.org  Fri Oct 20 13:13:55 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Fri, 20 Oct 2023 13:13:55 GMT
Subject: RFR: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics [v6]
In-Reply-To: 
References: 
Message-ID: 

> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
> 
> Tests:
> Performance tests on t-head board:
> With intrinsics:
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
> 
> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
> 
> Regression tests: tier1, hotspot:tier2 on risc-v board.
> 
> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
> 
> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> index 6cd1353907e..0bee25366bf 100644
> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>  
>      @Benchmark
>      public double  copySignDouble() {
> -        return  Math.copySign(double81, doubleNegative12);
> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>      }
>  
>      @Benchmark
>      public float  copySignFloat() {
> -        return  Math.copySign(floatNegative99, float1);
> +        return  Math.copySign(floatNegative99, float1) + Math.copySign(eFloat, float1) + Math.copySign...

Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision:

  Fix pipe classes inside copysign

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16186/files
  - new: https://git.openjdk.org/jdk/pull/16186/files/c79fb9e6..b6e0b569

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16186&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16186/head:pull/16186

PR: https://git.openjdk.org/jdk/pull/16186

From rriggs at openjdk.org  Fri Oct 20 13:19:50 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Oct 2023 13:19:50 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v3]
In-Reply-To: <4y-KQjPsCcPO-cHPrOZR2XL06zVnHjwqky5BIZOB-m0=.66bb6778-0f4d-4fca-b18b-f7aa12b94de0@github.com>
References: 
 
 <4y-KQjPsCcPO-cHPrOZR2XL06zVnHjwqky5BIZOB-m0=.66bb6778-0f4d-4fca-b18b-f7aa12b94de0@github.com>
Message-ID: 

On Fri, 21 Apr 2023 13:33:37 GMT, Mahendra Chhipa  wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comment.
>
> Thanks for your review comments. I will implement them and push again.

@mahendrachhipa it is conventional and preferred to allow reviewers and people who have commented on a PR a day to review/re-review before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13537#issuecomment-1772724008

From dnsimon at openjdk.org  Fri Oct 20 13:34:02 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 20 Oct 2023 13:34:02 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
Message-ID: 

The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module renami
 ng, including adjusting the qualified export.

-------------

Commit messages:
 - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

Changes: https://git.openjdk.org/jdk/pull/16189/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16189&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318027
  Stats: 40 lines in 10 files changed: 0 ins; 14 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/16189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16189/head:pull/16189

PR: https://git.openjdk.org/jdk/pull/16189

From weijun.wang at oracle.com  Fri Oct 20 13:42:44 2023
From: weijun.wang at oracle.com (Wei-Jun Wang)
Date: Fri, 20 Oct 2023 13:42:44 +0000
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/
 native GSS introduced by 8303809
In-Reply-To: 
References: <20231019220916.GG202255@twosigma.com>
 
Message-ID: 

Hi Nico,

I've filed a bug at https://bugs.openjdk.org/browse/JDK-8318599. Will look into it.

Thanks,
Max

> On Oct 19, 2023, at 10:39 PM, Nico Williams  wrote:
> 
> Also, a colleague informs me that 17.0.5 (as packaged by Debian) w/o `-Djdk.spnego.cache=false` doesn't exhibit the double-free/use-after-free crashes (as expected), but:
> 
>> I do see some "Authentication failure" / and "java.lang.NullPointerException: Cannot invoke "sun.net.www.protocol.http.Negotiator.nextToken(byte[])" because "this.negotiator" is null".
> 
> That seems to support the idea that the `AuthCache` is harmful.
> 
> Nico
> --
> 
> 
> 


From erikj at openjdk.org  Fri Oct 20 13:44:28 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 20 Oct 2023 13:44:28 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon  wrote:

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16189#pullrequestreview-1690071929

From ihse at openjdk.org  Fri Oct 20 13:48:35 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 20 Oct 2023 13:48:35 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon  wrote:

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.

Build changes look trivially good.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16189#pullrequestreview-1690080140

From jvernee at openjdk.org  Fri Oct 20 13:59:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Oct 2023 13:59:54 GMT
Subject: RFR: 8318598: FFM stylistic cleanups
Message-ID: <-Hp35kcnAKUsQGOmmBVqTyyzwfql47ZLh_kEHFqJnHM=.49fb44ce-9491-47f3-bd7c-d9ed9a5e34b6@github.com>

Port over stylistic changes from the panama-foreign repo. The following PRs are included:

- https://github.com/openjdk/panama-foreign/pull/863
- https://github.com/openjdk/panama-foreign/pull/888
- https://github.com/openjdk/panama-foreign/pull/889
- https://github.com/openjdk/panama-foreign/pull/893
- https://github.com/openjdk/panama-foreign/pull/894
- https://github.com/openjdk/panama-foreign/pull/897
- https://github.com/openjdk/panama-foreign/pull/906

Testing: `jdk_foreign`

-------------

Commit messages:
 - Fix sonar issues and thread safety bug
 - Rename max alignment constants for heap segments
 - Modernize code
 - Fix typos
 - Fix the use of final and static
 - Remove unused imports
 - Clean up StringSupport

Changes: https://git.openjdk.org/jdk/pull/16286/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16286&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318598
  Stats: 310 lines in 34 files changed: 54 ins; 80 del; 176 mod
  Patch: https://git.openjdk.org/jdk/pull/16286.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16286/head:pull/16286

PR: https://git.openjdk.org/jdk/pull/16286

From lucy at openjdk.org  Fri Oct 20 14:00:35 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 20 Oct 2023 14:00:35 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 08:38:22 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bump up argument counts in TestLargeStub to their maximum

s390 part looks good now. 
I did not check the shared code nor the other CPU architectures.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16201#pullrequestreview-1690103693

From mcimadamore at openjdk.org  Fri Oct 20 14:04:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Oct 2023 14:04:36 GMT
Subject: RFR: 8318598: FFM stylistic cleanups
In-Reply-To: <-Hp35kcnAKUsQGOmmBVqTyyzwfql47ZLh_kEHFqJnHM=.49fb44ce-9491-47f3-bd7c-d9ed9a5e34b6@github.com>
References: <-Hp35kcnAKUsQGOmmBVqTyyzwfql47ZLh_kEHFqJnHM=.49fb44ce-9491-47f3-bd7c-d9ed9a5e34b6@github.com>
Message-ID: 

On Fri, 20 Oct 2023 13:35:59 GMT, Jorn Vernee  wrote:

> Port over stylistic changes from the panama-foreign repo. The following PRs are included:
> 
> - https://github.com/openjdk/panama-foreign/pull/863
> - https://github.com/openjdk/panama-foreign/pull/888
> - https://github.com/openjdk/panama-foreign/pull/889
> - https://github.com/openjdk/panama-foreign/pull/893
> - https://github.com/openjdk/panama-foreign/pull/894
> - https://github.com/openjdk/panama-foreign/pull/897
> - https://github.com/openjdk/panama-foreign/pull/906
> 
> Testing: `jdk_foreign`

Looks good

src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 86:

> 84:         ensureInitialized();
> 85:         Objects.requireNonNull(arr);
> 86:         long byteSize = (long)arr.length * Utils.BaseAndScale.BYTE.scale();

Thanks for fixing up those

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16286#pullrequestreview-1690113999
PR Review Comment: https://git.openjdk.org/jdk/pull/16286#discussion_r1367017251

From mcimadamore at openjdk.org  Fri Oct 20 14:04:59 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Oct 2023 14:04:59 GMT
Subject: RFR: 8318601: Remove javadoc text about restricted methods
Message-ID: 

This simple PR removes the extra verbiage from the javadoc of all the restricted methods.
Since now javadoc will automatically generate better "bubbles" for restricted methods, this wording is no longer necessary.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/16287/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16287&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318601
  Stats: 40 lines in 5 files changed: 0 ins; 40 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16287/head:pull/16287

PR: https://git.openjdk.org/jdk/pull/16287

From rgiulietti at openjdk.org  Fri Oct 20 14:06:41 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 20 Oct 2023 14:06:41 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v3]
In-Reply-To: <6Vaf7kkwBnKX-wRwN-Oj4Mw7wwl5x0zq6e6u5FQDcH0=.ec0993d2-928f-4828-95e5-5a6fefdc8ce5@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 <2AUQJBYNCZaitrlfcUz1__tb_IEPw3BGfp1R8xmiMS0=.c2bf986d-2164-4931-b3f9-3d1f32cd345f@github.com>
 
 <6Vaf7kkwBnKX-wRwN-Oj4Mw7wwl5x0zq6e6u5FQDcH0=.ec0993d2-928f-4828-95e5-5a6fefdc8ce5@github.com>
Message-ID: 

On Fri, 20 Oct 2023 11:04:28 GMT, Shaojin Wen  wrote:

>> src/java.base/share/classes/java/util/FormatProcessor.java line 247:
>> 
>>> 245:                 throw new MissingFormatArgumentException(group + " is not immediately followed by an embedded expression");
>>> 246:             } else {
>>> 247:                 throw new UnknownFormatConversionException(String.valueOf(c));
>> 
>> I don't think this exception is thrown by the original code.
>
> I added these tests to show that the exceptions and messages thrown are the same as before.
> 
> 
> // test/jdk/java/lang/template/FormatterBuilder.java
> assertThrows(
>         MissingFormatArgumentException.class,
>         () -> fmt. "%10ba{ false }",
>         "Format specifier '%10b is not immediately followed by an embedded expression'");
> 
> assertThrows(
>         MissingFormatArgumentException.class,
>         () ->fmt. "%ba{ false }",
>         "Format specifier '%b is not immediately followed by an embedded expression'");
> 
> assertThrows(
>         MissingFormatArgumentException.class,
>         () ->fmt. "%b",
>         "Format specifier '%b is not immediately followed by an embedded expression'");
> assertThrows(
>         UnknownFormatConversionException.class,
>         () ->fmt. "%0",
>         "Conversion = '0'");

I'm referring specifically to this method, regardless of the tests.

The invocation `findFormat("%0", )` simply returns `false` in the original code, but throws in the proposed code.
It's way easier to be confident that a local re-implementation, as done here, is correct if the behavior is externally the same.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1367005711

From alanb at openjdk.org  Fri Oct 20 14:26:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 14:26:39 GMT
Subject: RFR: 8318601: Remove javadoc text about restricted methods
In-Reply-To: 
References: 
Message-ID: 

On Fri, 20 Oct 2023 13:59:16 GMT, Maurizio Cimadamore  wrote:

> This simple PR removes the extra verbiage from the javadoc of all the restricted methods.
> Since now javadoc will automatically generate better "bubbles" for restricted methods, this wording is no longer necessary.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16287#pullrequestreview-1690164559

From kvn at openjdk.org  Fri Oct 20 14:30:42 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 20 Oct 2023 14:30:42 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
In-Reply-To: 
References: 
Message-ID: <7hSMbF0mvl3GkzUPIzIefjeU8iJBXCWzkFN86aj0i78=.3f7b5391-6757-442f-8ba1-b5d9b8b2dbe2@github.com>

On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon  wrote:

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.

Why you replaced pair of copyright years with one year in module-info.Java files? Instead of updating last year only.
Why also update 'since' there?
Even if you changed location these files existed already.

-------------

Changes requested by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16189#pullrequestreview-1690172543

From mcimadamore at openjdk.org  Fri Oct 20 14:32:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 20 Oct 2023 14:32:44 GMT
Subject: Integrated: 8318601: Remove javadoc text about restricted methods
In-Reply-To: 
References: 
Message-ID: 

On Fri, 20 Oct 2023 13:59:16 GMT, Maurizio Cimadamore  wrote:

> This simple PR removes the extra verbiage from the javadoc of all the restricted methods.
> Since now javadoc will automatically generate better "bubbles" for restricted methods, this wording is no longer necessary.

This pull request has now been integrated.

Changeset: 91442878
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/91442878b7b7b2e131621958de4942f30bbf3537
Stats:     40 lines in 5 files changed: 0 ins; 40 del; 0 mod

8318601: Remove javadoc text about restricted methods

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/16287

From igavrilin at openjdk.org  Fri Oct 20 14:34:48 2023
From: igavrilin at openjdk.org (Ilya Gavrilin)
Date: Fri, 20 Oct 2023 14:34:48 GMT
Subject: Integrated: 8317971: RISC-V: implement copySignF/D and signumF/D
 intrinsics
In-Reply-To: 
References: 
Message-ID: <2KZQtr80bQETNa18fg-tFW79W3iIAuq0AFTn2mzl2Fg=.727f8de4-0f69-45db-a179-f1b11269fd29@github.com>

On Fri, 13 Oct 2023 15:36:56 GMT, Ilya Gavrilin  wrote:

> Hi all, please review this changes into risc-v floating point copysign and signum intrinsics.
> CopySign - returns first argument with the sign of second. On risc-v we have `fsgnj.x` instruction, which can implement this intrinsic.
> Signum - returns input value if it is +/- 0.0 or NaN, otherwise 1.0 with the sign of input value returned.  On risc-v we can use `fclass.x` to specify type of input value and return appropriate value.
> 
> Tests:
> Performance tests on t-head board:
> With intrinsics:
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  34156.580 ?   76.272  ops/ms
> MathBench.copySignFloat        0  thrpt    8  34181.731 ?   38.182  ops/ms
> MathBench.signumDouble         0  thrpt    8  31977.258 ? 1122.327  ops/ms
> MathBench.signumFloat          0  thrpt    8  31836.852 ?   56.013  ops/ms
> 
> Intrinsics turned off (`-XX:+UnlockDiagnosticVMOptions -XX:-UseCopySignIntrinsic -XX:-UseSignumIntrinsic`):
> 
> Benchmark                 (seed)   Mode  Cnt      Score      Error   Units
> MathBench.copySignDouble       0  thrpt    8  31000.996 ?  943.094  ops/ms
> MathBench.copySignFloat        0  thrpt    8  30678.016 ?   28.087  ops/ms
> MathBench.signumDouble         0  thrpt    8  25435.010 ? 2047.085  ops/ms
> MathBench.signumFloat          0  thrpt    8  25257.058 ?   79.175  ops/ms
> 
> Regression tests: tier1, hotspot:tier2 on risc-v board.
> 
> Also, changed name of one micro test: before we had: `sigNumDouble` and `signumFloat` tests, they does not matches to `signum` or `sigNum`. Now we have similar part: `signum`.
> Performance tests has been changed a bit, to check intrinsics result better, diff to modify tests:
> 
> diff --git a/test/micro/org/openjdk/bench/java/lang/MathBench.java b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> index 6cd1353907e..0bee25366bf 100644
> --- a/test/micro/org/openjdk/bench/java/lang/MathBench.java
> +++ b/test/micro/org/openjdk/bench/java/lang/MathBench.java
> @@ -143,12 +143,12 @@ public double  ceilDouble() {
>  
>      @Benchmark
>      public double  copySignDouble() {
> -        return  Math.copySign(double81, doubleNegative12);
> +        return  Math.copySign(double81, doubleNegative12) + Math.copySign(double81, double2) + Math.copySign(double4Dot1, doubleNegative12);
>      }
>  
>      @Benchmark
>      public float  copySignFloat() {
> -        return  Math.copySign(floatNegative99, float1);
> +        return  Math.copySign(floatNegative99, float1) + Math.copySign(eFloat, float1) + Math.copySign...

This pull request has now been integrated.

Changeset: 5a97411f
Author:    Ilya Gavrilin 
Committer: Vladimir Kempik 
URL:       https://git.openjdk.org/jdk/commit/5a97411f857b0bc9e70b417efa76a5fd5f887fe0
Stats:     90 lines in 5 files changed: 89 ins; 0 del; 1 mod

8317971: RISC-V: implement copySignF/D and signumF/D intrinsics

Reviewed-by: fyang, vkempik

-------------

PR: https://git.openjdk.org/jdk/pull/16186

From alanb at openjdk.org  Fri Oct 20 14:37:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 14:37:39 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 15:21:55 GMT, Calvin Cheung  wrote:

>> Please review this changeset for adding support for `--module` (-m) option for CDS.
>> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
>> 
>> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify some code in modules.cpp

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 472:

> 470: 
> 471:         // If -Xshare:dump and mainModule are specified, check if the mainModule
> 472:         // is in the runtime image and not in the upgrade module path. If so,

Small typo here, should be "on the upgrade module path" rather than "in".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367062501

From dnsimon at openjdk.org  Fri Oct 20 14:42:28 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 20 Oct 2023 14:42:28 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
In-Reply-To: <7hSMbF0mvl3GkzUPIzIefjeU8iJBXCWzkFN86aj0i78=.3f7b5391-6757-442f-8ba1-b5d9b8b2dbe2@github.com>
References: 
 <7hSMbF0mvl3GkzUPIzIefjeU8iJBXCWzkFN86aj0i78=.3f7b5391-6757-442f-8ba1-b5d9b8b2dbe2@github.com>
Message-ID: 

On Fri, 20 Oct 2023 14:27:43 GMT, Vladimir Kozlov  wrote:

> Why you replaced pair of copyright years with one year in module-info.Java files? Instead of updating last year only. Why also update 'since' there? Even if you changed location these files existed already.

The files may be renamed from git's point of view, but I would argue that these are new modules and so should have a new `@since` tag. Otherwise, someone seeing that `jdk.compiler.graal` existed `@since 9` may be a little surprised/confused if they look for it in a JDK 9 binary. Same thinking applies to the copyright dates. Happy to fix it if this is the wrong way to think about it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1772866757

From alanb at openjdk.org  Fri Oct 20 14:51:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 14:51:37 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 15:21:55 GMT, Calvin Cheung  wrote:

>> Please review this changeset for adding support for `--module` (-m) option for CDS.
>> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
>> 
>> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify some code in modules.cpp

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 491:

> 489:                                         cf,
> 490:                                         clf);
> 491:             if (!hasSplitPackages) {

Did you mean to drop the hasIncubatorModules check? Incubator modules are not resolved by default.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367080656

From kvn at openjdk.org  Fri Oct 20 14:56:36 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 20 Oct 2023 14:56:36 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon  wrote:

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.

Copyright is associated with file and should be kept, only update last year.
I don't know rules about 'since'. But there will be no confusion for developers. Everyone knows that these files were created for Graal from the start.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1772894022

From alanb at openjdk.org  Fri Oct 20 15:03:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 15:03:30 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 15:21:55 GMT, Calvin Cheung  wrote:

>> Please review this changeset for adding support for `--module` (-m) option for CDS.
>> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
>> 
>> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify some code in modules.cpp

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 481:

> 479:                     canArchive = true;
> 480:                 }
> 481:             }

An alternative to avoid the 3 levels of if expressions is to use:

        String scheme = systemModuleFinder.find(mainModule)
                .stream()
                .map(ModuleReference::location)
                .flatMap(Optional::stream)
                .findAny()
                .map(URI::getScheme)
                .orElse(null);
        if ("jrt".equalsIgnoreCase(scheme)) {
            canArchive = true;
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367104266

From lancea at openjdk.org  Fri Oct 20 15:24:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 20 Oct 2023 15:24:53 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v3]
In-Reply-To: <4y-KQjPsCcPO-cHPrOZR2XL06zVnHjwqky5BIZOB-m0=.66bb6778-0f4d-4fca-b18b-f7aa12b94de0@github.com>
References: 
 
 <4y-KQjPsCcPO-cHPrOZR2XL06zVnHjwqky5BIZOB-m0=.66bb6778-0f4d-4fca-b18b-f7aa12b94de0@github.com>
Message-ID: <2X-w09tVdSkgAWkpW9K0ZYAEzwyvomWK5M446LK1cxw=.fad9a849-497d-4c01-8714-972ec5915fc5@github.com>

On Fri, 21 Apr 2023 13:33:37 GMT, Mahendra Chhipa  wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comment.
>
> Thanks for your review comments. I will implement them and push again.

> @mahendrachhipa it is conventional and preferred to allow reviewers and people who have commented on a PR a day to review/re-review before integrating.

Just to follow on to Roger's comment.  There have been many changes to this PR since Joe approved this on April 28th so we definitely should have given more time to allow for the reviewers to go through the latest updates and provide feedback and/or approve

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13537#issuecomment-1772941378

From dnsimon at openjdk.org  Fri Oct 20 15:32:55 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 20 Oct 2023 15:32:55 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  fix copyright dates and @since tags to reflect history

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16189/files
  - new: https://git.openjdk.org/jdk/pull/16189/files/6b729561..cc0474b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16189&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16189&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16189/head:pull/16189

PR: https://git.openjdk.org/jdk/pull/16189

From jvernee at openjdk.org  Fri Oct 20 15:43:48 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 20 Oct 2023 15:43:48 GMT
Subject: Integrated: 8318598: FFM stylistic cleanups
In-Reply-To: <-Hp35kcnAKUsQGOmmBVqTyyzwfql47ZLh_kEHFqJnHM=.49fb44ce-9491-47f3-bd7c-d9ed9a5e34b6@github.com>
References: <-Hp35kcnAKUsQGOmmBVqTyyzwfql47ZLh_kEHFqJnHM=.49fb44ce-9491-47f3-bd7c-d9ed9a5e34b6@github.com>
Message-ID: <41cC3kTO6WGCP5uWMKqt7zzuBskfxHpS-t7sMOADq2c=.e6ab35a5-52ea-4a1a-b1de-9cee651157f8@github.com>

On Fri, 20 Oct 2023 13:35:59 GMT, Jorn Vernee  wrote:

> Port over stylistic changes from the panama-foreign repo. The following PRs are included:
> 
> - https://github.com/openjdk/panama-foreign/pull/863
> - https://github.com/openjdk/panama-foreign/pull/888
> - https://github.com/openjdk/panama-foreign/pull/889
> - https://github.com/openjdk/panama-foreign/pull/893
> - https://github.com/openjdk/panama-foreign/pull/894
> - https://github.com/openjdk/panama-foreign/pull/897
> - https://github.com/openjdk/panama-foreign/pull/906
> 
> Testing: `jdk_foreign`

This pull request has now been integrated.

Changeset: 8065233e
Author:    Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/8065233e8b8976929e1975c9a74cf70bf3485ae2
Stats:     310 lines in 34 files changed: 54 ins; 80 del; 176 mod

8318598: FFM stylistic cleanups

Co-authored-by: Per Minborg 
Co-authored-by: Maurizio Cimadamore 
Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/16286

From dnsimon at openjdk.org  Fri Oct 20 15:45:50 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 20 Oct 2023 15:45:50 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  re-fix since tags to reflect current JDK release

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16189/files
  - new: https://git.openjdk.org/jdk/pull/16189/files/cc0474b2..193e22a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16189&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16189&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16189/head:pull/16189

PR: https://git.openjdk.org/jdk/pull/16189

From mr at openjdk.org  Fri Oct 20 15:45:52 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Fri, 20 Oct 2023 15:45:52 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 15:32:55 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright dates and @since tags to reflect history

The `@since` tag should reflect the release in which the tagged element was introduced (i.e., 22), not the release in which some predecessor of the element was introduced.

Vladimir was right about the copyright dates ? they should record the year in which the content was created and last updated, regardless of the content?s name.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1772966065
PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1772973225

From dnsimon at openjdk.org  Fri Oct 20 15:45:53 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 20 Oct 2023 15:45:53 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 15:32:55 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright dates and @since tags to reflect history

Ok, thanks for the clarification. What about the copyright dates on the `module-info.java` files?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1772970273

From alanb at openjdk.org  Fri Oct 20 16:18:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 16:18:41 GMT
Subject: RFR: 8318598: FFM stylistic cleanups
In-Reply-To: <-Hp35kcnAKUsQGOmmBVqTyyzwfql47ZLh_kEHFqJnHM=.49fb44ce-9491-47f3-bd7c-d9ed9a5e34b6@github.com>
References: <-Hp35kcnAKUsQGOmmBVqTyyzwfql47ZLh_kEHFqJnHM=.49fb44ce-9491-47f3-bd7c-d9ed9a5e34b6@github.com>
Message-ID: 

On Fri, 20 Oct 2023 13:35:59 GMT, Jorn Vernee  wrote:

> Port over stylistic changes from the panama-foreign repo. The following PRs are included:
> 
> - https://github.com/openjdk/panama-foreign/pull/863
> - https://github.com/openjdk/panama-foreign/pull/888
> - https://github.com/openjdk/panama-foreign/pull/889
> - https://github.com/openjdk/panama-foreign/pull/893
> - https://github.com/openjdk/panama-foreign/pull/894
> - https://github.com/openjdk/panama-foreign/pull/897
> - https://github.com/openjdk/panama-foreign/pull/906
> 
> Testing: `jdk_foreign`

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 635:

> 633:                             int elementCount) {
> 634: 
> 635:         var dstInfo = Utils.BaseAndScale.of(dstArray);

This is a case where I personally wouldn't use `var` because RHS is not clear, I have no idea what type dstInfo is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16286#discussion_r1367209975

From alanb at openjdk.org  Fri Oct 20 16:22:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 16:22:32 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-fix since tags to reflect current JDK release

The module config and test update looks fine.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16189#pullrequestreview-1690440898

From asemenyuk at openjdk.org  Fri Oct 20 16:30:33 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 20 Oct 2023 16:30:33 GMT
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 04:23:22 GMT, Alexander Matveev  wrote:

>> - Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
>> - If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
>>> Error: "codesign" failed with following output:
>>> test: no identity found
>> 
>>> Error: "productbuild" failed with following output:
>>> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
>> - Added error handling not to allow invalid combinations of signing options.
>> - Updated signing tests to test new changes.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311877: [macos] Add CLI options to provide signing identity directly to codesign and productbuild [v2]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16085#pullrequestreview-1690463122

From duke at openjdk.org  Fri Oct 20 16:30:46 2023
From: duke at openjdk.org (yaqsun)
Date: Fri, 20 Oct 2023 16:30:46 GMT
Subject: Integrated: 8316563: test tools/jpackage/linux/LinuxResourceTest.java
 fails on CentOS Linux release 8.5.2111 and Fedora 27
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 03:32:55 GMT, yaqsun  wrote:

> on some RHEL Linux 8.X and Fedora 27 machines , we run into errors in test tools/jpackage/linux/LinuxResourceTest.java.
> It's the same problem as https://bugs.openjdk.org/browse/JDK-8314121. 
> But after 8314121, tools/jpackage/linux/LinuxResourceTest.java still reappears. tools/jpackage/linux/LinuxResourceTest.java does not use file src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec.

This pull request has now been integrated.

Changeset: 52814994
Author:    sunyaqi 
Committer: Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/52814994efc4831fdbc1f796ed1db6ae88cb616c
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8316563: test tools/jpackage/linux/LinuxResourceTest.java fails on CentOS Linux release 8.5.2111 and Fedora 27

Reviewed-by: asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/15832

From asemenyuk at openjdk.org  Fri Oct 20 16:33:39 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 20 Oct 2023 16:33:39 GMT
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 20 Oct 2023 04:23:56 GMT, Alexander Matveev  wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8311877: [macos] Add CLI options to provide signing identity directly to codesign and productbuild [v2]
>
> Yes, you got it right. I agree it does not make sense to consider error if `--mac-sign` is not specified. I fixed it as you suggested. `--mac-app-image-sign-identity` will be ignored and no signing is done if `--mac-sign` is not specified.
> 
> Also, updated `SigningPackageTest.java` to include tests for cases when only app-image is being signed or when only pkg is being signed using sign identity options.

@sashamatveev would you comment on Michael Hall's ide about codesign verification idea?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16085#issuecomment-1773044912

From vklang at openjdk.org  Fri Oct 20 16:34:49 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 20 Oct 2023 16:34:49 GMT
Subject: Integrated: 8318420 : AbstractPipeline invokes overridden method in
 constructor
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 Oct 2023 09:45:53 GMT, Viktor Klang  wrote:

> This PR corrects so that `opIsStateful()` is not invoked as a part of the java.util.stream.AbstractPipeline constructor?as `opIsStateful()` is intended to be overridden by subclasses, and as their own constructors have not run when their superclass constructor runs, this means that `opIsStateful()` cannot base its return value on any class members of the subclass.
> 
> Since `opIsStateful()` is only needed for parallel streams, we can therefor defer the invocation of `opIsStateful()` until evaluation-time, and as such we can remove the need for having an instance field to store the result of the invocation?making Stream instances potentially a tiny bit smaller, reducing Stream-construction overhead, while still preserving semantics.

This pull request has now been integrated.

Changeset: 200b5a27
Author:    Viktor Klang 
Committer: Paul Sandoz 
URL:       https://git.openjdk.org/jdk/commit/200b5a27d4bc77e2628a80d8166ee5d6057ab0c5
Stats:     24 lines in 1 file changed: 15 ins; 8 del; 1 mod

8318420: AbstractPipeline invokes overridden method in constructor

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/16239

From vklang at openjdk.org  Fri Oct 20 16:35:43 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 20 Oct 2023 16:35:43 GMT
Subject: Integrated: 8318421 : AbstractPipeline.sourceStageSpliterator() chases
 pointers needlessly
In-Reply-To: <_51DHI2JBgmgI3Gqc4dvWH59J2ujKMxBUCYrzmD2l_w=.2eb7c6f2-e02d-4927-b31d-05b3f2e5bb07@github.com>
References: <_51DHI2JBgmgI3Gqc4dvWH59J2ujKMxBUCYrzmD2l_w=.2eb7c6f2-e02d-4927-b31d-05b3f2e5bb07@github.com>
Message-ID: 

On Wed, 18 Oct 2023 10:14:08 GMT, Viktor Klang  wrote:

> Removes a few unnecessary dereferences of `sourceStage`.

This pull request has now been integrated.

Changeset: 21215753
Author:    Viktor Klang 
Committer: Paul Sandoz 
URL:       https://git.openjdk.org/jdk/commit/21215753c05681311be304f8994a97caa8e33ce2
Stats:     10 lines in 1 file changed: 1 ins; 0 del; 9 mod

8318421: AbstractPipeline.sourceStageSpliterator() chases pointers needlessly

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/16241

From alanb at openjdk.org  Fri Oct 20 16:48:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Oct 2023 16:48:38 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 18 Oct 2023 15:59:13 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update lastModifiedTime comment

src/java.base/share/classes/java/util/zip/ZipFile.java line 1431:

> 1429:                      * the same file is opened more than once and where it has been
> 1430:                      * modified in the mean-time
> 1431:                      */

The code change to the hashCode method is fine but I think the comments added to both hashCode + equals are still a bit confusing because they hint that the last modified time is used to detect if a zip file has been modified. What would you think about dropping these comments and instead put a class file comment on Key to say that it represents a key to a zip file. It key is based on the file key if available, or the canonical path if the file key is not available. The key is also based on the file's last modified time to allow for cases where a zip file is re-opened after it has been modified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1367246534

From joehw at openjdk.org  Fri Oct 20 17:23:41 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 20 Oct 2023 17:23:41 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed
 [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 19 Oct 2023 11:43:57 GMT, Mahendra Chhipa  wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added indentation to generate the properly indented code.
>   Revert back to Formatter class from HexFormat class, so that Any Java version serialization code
>   can be generated.
>   Added "Mechanically generated" notation to already generated classes with Old Java versions.

Agree with Roger and Lance. My previous approval could not be counted towards all the changes that had happened afterwards.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13537#issuecomment-1773114819

From jlu at openjdk.org  Fri Oct 20 17:40:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Oct 2023 17:40:43 GMT
Subject: Integrated: JDK-7061097: [Doc] Inconsistenency between the spec and
 the implementation for DateFormat.Field
In-Reply-To: 
References: 
Message-ID: <4Gv7scNRzPIXmvWkj7cjaK8Ual2fWSroDEe_ngdorHQ=.2c59334b-6515-4c65-b0fb-a3a20bf5dde5@github.com>

On Thu, 19 Oct 2023 21:31:13 GMT, Justin Lu  wrote:

> Please review this PR which adjusts the specification of `DateFormat.Field::getCalendarField` to conform to the implementation.
> 
> `getCalendarField()` claims that it will return -1 if there is no corresponding `Calendar` constant.
> 
> Although the built-in DateFormat.Fields with no associated `Calendar` constant are created with a `calendarField` equal to -1, a subclass can create a DateFormat.Field with no associated `Calendar` constant with `calendarField` equal to anything.
> 
> The specification of `getCalendarField()` should be adjusted to reflect this. That is, a separate implementation may or may not return -1 if there is no associated `Calendar` constant.

This pull request has now been integrated.

Changeset: 4dfa3799
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/4dfa3799a60cb11092b699db5bc0cc1f44d24484
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

7061097: [Doc] Inconsistenency between the spec and the implementation for DateFormat.Field

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/16279

From naoto at openjdk.org  Fri Oct 20 18:03:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 20 Oct 2023 18:03:53 GMT
Subject: RFR: 8318569: Add getter methods for Locale and Patterns in ListFormat
Message-ID: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>

Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

-------------

Commit messages:
 - Simplified the method spec
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/16293/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16293&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318569
  Stats: 60 lines in 2 files changed: 59 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16293.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16293/head:pull/16293

PR: https://git.openjdk.org/jdk/pull/16293

From kvn at openjdk.org  Fri Oct 20 18:08:30 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 20 Oct 2023 18:08:30 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-fix since tags to reflect current JDK release

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16189#pullrequestreview-1690675532

From dl at openjdk.org  Fri Oct 20 18:10:49 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 20 Oct 2023 18:10:49 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v51]
In-Reply-To: 
References: 
Message-ID: <98z9ryfCOAY8EUtWbNnlghSnCFOs9L2iAYyMQuL40vI=.f706461d-575f-485e-b95c-42b4353c805f@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Ensure liveness for InterruptibleTasks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/005ea626..f46aa909

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=49-50

  Stats: 92 lines in 1 file changed: 28 ins; 13 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From dl at openjdk.org  Fri Oct 20 18:26:53 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 20 Oct 2023 18:26:53 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v52]
In-Reply-To: 
References: 
Message-ID: 

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:

 - Merge master
 - Ensure liveness for InterruptibleTasks
 - Merge branch 'openjdk:master' into JDK-8288899
 - More cleanup
 - Merge branch 'openjdk:master' into JDK-8288899
 - better window encoding
 - Merge branch 'openjdk:master' into JDK-8288899
 - cleanup
 - Merge branch 'openjdk:master' into JDK-8288899
 - refactor termination
 - ... and 90 more: https://git.openjdk.org/jdk/compare/66d90d5d...faaf54b2

-------------

Changes: https://git.openjdk.org/jdk/pull/14301/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=51
  Stats: 4537 lines in 18 files changed: 2471 ins; 668 del; 1398 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From jjg at openjdk.org  Fri Oct 20 18:36:37 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 20 Oct 2023 18:36:37 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-fix since tags to reflect current JDK release

The proposed name `jdk.compiler.graal` makes it seem like the module is strongly related to the `jdk.compiler` module, which contains `javac` and related tools, whereas these modules are completely unrelated.

Is there not a better name that can be used?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1773211363

From mr at openjdk.org  Fri Oct 20 20:13:35 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Fri, 20 Oct 2023 20:13:35 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <6GSrZIWvORLQC7cBdvhMRKa7lKfEsHqp1Umq82YEZg0=.3c14d749-f5e4-49f1-ab54-17a0d8f2c78d@github.com>

On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-fix since tags to reflect current JDK release

Jon makes a good point. If memory serves, wasn?t the name `jdk.graal.compiler` suggested previously? That would avoid the overlap with the name of the existing `jdk.compiler` module.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1773335627

From ccheung at openjdk.org  Fri Oct 20 20:32:48 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 20 Oct 2023 20:32:48 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16016/files
  - new: https://git.openjdk.org/jdk/pull/16016/files/471f6414..6c82fde0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16016/head:pull/16016

PR: https://git.openjdk.org/jdk/pull/16016

From ccheung at openjdk.org  Fri Oct 20 20:32:52 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 20 Oct 2023 20:32:52 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 20 Oct 2023 14:34:52 GMT, Alan Bateman  wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify some code in modules.cpp
>
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 472:
> 
>> 470: 
>> 471:         // If -Xshare:dump and mainModule are specified, check if the mainModule
>> 472:         // is in the runtime image and not in the upgrade module path. If so,
> 
> Small typo here, should be "on the upgrade module path" rather than "in".

Fixed

> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 481:
> 
>> 479:                     canArchive = true;
>> 480:                 }
>> 481:             }
> 
> An alternative to avoid the 3 levels of if expressions is to use:
> 
>         String scheme = systemModuleFinder.find(mainModule)
>                 .stream()
>                 .map(ModuleReference::location)
>                 .flatMap(Optional::stream)
>                 .findAny()
>                 .map(URI::getScheme)
>                 .orElse(null);
>         if ("jrt".equalsIgnoreCase(scheme)) {
>             canArchive = true;
>         }

I tried the above but got the following build error:

Optimizing the exploded image
Error occurred during initialization of boot layer
java.lang.NullPointerException
ExplodedImageOptimize.gmk:39: recipe for target '/scratch/cccheung/ws/git/curr_jdk/build/mywork-debug/jdk/_optimize_image_exec.marker' failed

Let's keep the existing code for now because I may need to refactor the code into a utility method for a upcoming RFE to support the --add-modules option.

> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 491:
> 
>> 489:                                         cf,
>> 490:                                         clf);
>> 491:             if (!hasSplitPackages) {
> 
> Did you mean to drop the hasIncubatorModules check? Incubator modules are not resolved by default.

Yes, because of the following code further up in the same method:

            if (!haveModulePath && addModules.isEmpty() && limitModules.isEmpty()) {
                systemModules = SystemModuleFinders.systemModules(mainModule);
                if (systemModules != null && !isPatched) {
                    needResolution = (traceOutput != null);
                    canArchive = true;
                }
            }
            if (systemModules == null) {
                // all system modules are observable
                systemModules = SystemModuleFinders.allSystemModules();
            }

`SystemModuleFinders.systemModules(mainModule)` returns null if `mainModule` is not null (I'm not sure why).
Then, the `SystemModuleFinders.allSystemModules()` returns the generated class `SystemModules$all` with the following method:

    public boolean hasIncubatorModules() {
        return true;
    }


Also, there's the following change:
`needResolution = (traceOutput != null) || CDS.isDumpingStaticArchive();`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367457252
PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367457043
PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367455686

From almatvee at openjdk.org  Fri Oct 20 20:42:28 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 20 Oct 2023 20:42:28 GMT
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 04:23:22 GMT, Alexander Matveev  wrote:

>> - Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
>> - If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
>>> Error: "codesign" failed with following output:
>>> test: no identity found
>> 
>>> Error: "productbuild" failed with following output:
>>> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
>> - Added error handling not to allow invalid combinations of signing options.
>> - Updated signing tests to test new changes.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311877: [macos] Add CLI options to provide signing identity directly to codesign and productbuild [v2]

Michael filed https://bugs.openjdk.org/browse/JDK-8318063 for codesign verification, so I would prefer to move discussion under this JBS issue on this topic.

For now I do not know if we need to add it. From my experience I never found case when codesign did not fail during signing, but signature verification failed. So, for now I think it is redundant and we will never get to signature verification step if something wrong since codesign will fail during signing. Only case I see is when we did not run codesign at all, but it means our entire signing is broken.

Michael, do you have any examples when you was able to sign application bundle via jpackage or manually, but codesign verification gave error?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16085#issuecomment-1773366403

From mik3hall at gmail.com  Fri Oct 20 20:53:37 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 20 Oct 2023 15:53:37 -0500
Subject: RFR: 8311877: [macos] Add CLI options to provide signing identity
 directly to codesign and productbuild [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 



> On Oct 20, 2023, at 3:42 PM, Alexander Matveev  wrote:
> 
> On Fri, 20 Oct 2023 04:23:22 GMT, Alexander Matveev > wrote:
> 
>>> - Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
>>> - If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
>>>> Error: "codesign" failed with following output:
>>>> test: no identity found
>>> 
>>>> Error: "productbuild" failed with following output:
>>>> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
>>> - Added error handling not to allow invalid combinations of signing options.
>>> - Updated signing tests to test new changes.
>> 
>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  8311877: [macos] Add CLI options to provide signing identity directly to codesign and productbuild [v2]
> 
> Michael filed https://bugs.openjdk.org/browse/JDK-8318063 for codesign verification, so I would prefer to move discussion under this JBS issue on this topic.
> 
> For now I do not know if we need to add it. From my experience I never found case when codesign did not fail during signing, but signature verification failed. So, for now I think it is redundant and we will never get to signature verification step if something wrong since codesign will fail during signing. Only case I see is when we did not run codesign at all, but it means our entire signing is broken.
> 
> Michael, do you have any examples when you was able to sign application bundle via jpackage or manually, but codesign verification gave error?
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/16085#issuecomment-1773366403


It might not be broken for you, although verification I wouldn?t think would do any harm. I did have one occasion where I thought jpackage signing was broken because verification failed. However it turned out this was because I was using Unix cp or mv on the application which didn?t work correctly. I changed to using macOS ditto and it worked fine. I think I saw you use something else different to copy the app but don?t remember what. 

This though would be an example where the user can do something that breaks signing, after the fact though, so not a perfect example. A verify at the end of jpackage would have told me that the problem wasn?t with jpackage. 

I think I had one or two other problems with signing on older versions but it has now been stable in my use for sometime. I could try to dig up the incidents if wanted. All fixed at this time as far as I know.

When I read the comments here it said something about being unable to guarantee it was correctly signed. I thought codesign verify would tell you that.

Mike

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From joehw at openjdk.org  Fri Oct 20 20:54:37 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 20 Oct 2023 20:54:37 GMT
Subject: RFR: 8318569: Add getter methods for Locale and Patterns in
 ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: 

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato  wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

Looks good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16293#pullrequestreview-1690887480

From rriggs at openjdk.org  Fri Oct 20 21:20:26 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Oct 2023 21:20:26 GMT
Subject: RFR: 8318569: Add getter methods for Locale and Patterns in
 ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: 

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato  wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16293#pullrequestreview-1690913429

From iris at openjdk.org  Fri Oct 20 21:25:35 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 20 Oct 2023 21:25:35 GMT
Subject: RFR: 8318569: Add getter methods for Locale and Patterns in
 ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: 

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato  wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

Corresponding CSR also Reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16293#pullrequestreview-1690917007

From dl at openjdk.org  Fri Oct 20 21:26:51 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 20 Oct 2023 21:26:51 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v53]
In-Reply-To: 
References: 
Message-ID: 

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge master
 - Ensure liveness for InterruptibleTasks
 - Merge branch 'openjdk:master' into JDK-8288899
 - More cleanup
 - Merge branch 'openjdk:master' into JDK-8288899
 - better window encoding
 - Merge branch 'openjdk:master' into JDK-8288899
 - cleanup
 - Merge branch 'openjdk:master' into JDK-8288899
 - ... and 91 more: https://git.openjdk.org/jdk/compare/a1a62d99...84f06bcf

-------------

Changes: https://git.openjdk.org/jdk/pull/14301/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=52
  Stats: 4537 lines in 18 files changed: 2471 ins; 668 del; 1398 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From prr at openjdk.org  Fri Oct 20 22:50:51 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Oct 2023 22:50:51 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v2]
In-Reply-To: 
References: 
Message-ID: 

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge remote-tracking branch 'upstream/master' into harfbuzz_panama
   Merge
 - remove tailing white space
 - use scaling
 - Fix windows build, remove perf. logging
 - Add test, fix bug
 - use allocateFrom
 - add offset param
 - suppressed restricted warnings, now builds but not running yet
 - Adapt to changed API for FFM final
 - Merge
 - ... and 8 more: https://git.openjdk.org/jdk/compare/af2f4bfa...984a8780

-------------

Changes: https://git.openjdk.org/jdk/pull/15476/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15476&range=01
  Stats: 1374 lines in 7 files changed: 1372 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15476/head:pull/15476

PR: https://git.openjdk.org/jdk/pull/15476

From prr at openjdk.org  Fri Oct 20 23:03:50 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Oct 2023 23:03:50 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v3]
In-Reply-To: 
References: 
Message-ID: 

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  Use new arrayElementVarHandle method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15476/files
  - new: https://git.openjdk.org/jdk/pull/15476/files/984a8780..2f759caf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15476&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15476&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15476/head:pull/15476

PR: https://git.openjdk.org/jdk/pull/15476

From darcy at openjdk.org  Fri Oct 20 23:33:33 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 20 Oct 2023 23:33:33 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases
In-Reply-To: 
References: 
Message-ID: 

On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy  wrote:

> A new paper
> 
>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

Keep alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15879#issuecomment-1773520605

From darcy at openjdk.org  Sat Oct 21 01:04:55 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 21 Oct 2023 01:04:55 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal
Message-ID: 

Add informative notes to BigInteger and BigDecimal about possible running times, etc.

-------------

Commit messages:
 - Appease jcheck.
 - JDK-8318476: Add resource consumption note to BigInteger and BigDecimal

Changes: https://git.openjdk.org/jdk/pull/16298/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318476
  Stats: 50 lines in 2 files changed: 48 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16298/head:pull/16298

PR: https://git.openjdk.org/jdk/pull/16298

From duke at openjdk.org  Sat Oct 21 01:22:04 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 21 Oct 2023 01:22:04 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v5]
In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
Message-ID: <4Svt2bqEKfvhgxaORRHwDTQQ7kqWN2UoD9pTusfZ0nM=.9c0cf5b5-201d-4fb5-ad70-5fedf512cdd8@github.com>

> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
> 
> The following are the test results based on MacBookPro M1 Pro: 
> 
> 
> -Benchmark                          Mode  Cnt     Score     Error  Units
> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
> 
> +Benchmark                          Mode  Cnt    Score    Error  Units
> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix from @rgiulietti 's review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/abb90227..289a0249

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=03-04

  Stats: 11 lines in 1 file changed: 3 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15776.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15776/head:pull/15776

PR: https://git.openjdk.org/jdk/pull/15776

From alanb at openjdk.org  Sat Oct 21 06:56:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Oct 2023 06:56:34 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 20 Oct 2023 20:22:31 GMT, Calvin Cheung  wrote:

> Yes, because of the following code further up in the same method:

I think what you are actually doing here is supporting archiving of the boot layer when the main module transitively depends on an incubator module. We might have to add more tests in this area as it doesn't look like this scenario is tested, at least not with CDS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367679300

From alanb at openjdk.org  Sat Oct 21 07:44:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Oct 2023 07:44:39 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Sat, 21 Oct 2023 06:54:16 GMT, Alan Bateman  wrote:

> > Yes, because of the following code further up in the same method:
> 
> I think what you are actually doing here is supporting archiving of the boot layer when the main module transitively depends on an incubator module. We might have to add more tests in this area as it doesn't look like this scenario is tested, at least not with CDS.

Just to add to this. The effect of this change is that a warning won't be emitted if you archive with a boot layer that contains a main module and an incubator module, e.g. main requires jdk.incubator.vector. In other words, `java -Xshare:off -m main` will print the expected warning, `java -Xshare:off -m main` will not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367685000

From alanb at openjdk.org  Sat Oct 21 07:54:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Oct 2023 07:54:27 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Sat, 21 Oct 2023 07:42:06 GMT, Alan Bateman  wrote:

>>> Yes, because of the following code further up in the same method:
>> 
>> I think what you are actually doing here is supporting archiving of the boot layer when the main module transitively depends on an incubator module. We might have to add more tests in this area as it doesn't look like this scenario is tested, at least not with CDS.
>
>> > Yes, because of the following code further up in the same method:
>> 
>> I think what you are actually doing here is supporting archiving of the boot layer when the main module transitively depends on an incubator module. We might have to add more tests in this area as it doesn't look like this scenario is tested, at least not with CDS.
> 
> Just to add to this. The effect of this change is that a warning won't be emitted if you archive with a boot layer that contains a main module and an incubator module, e.g. main requires jdk.incubator.vector. In other words, `java -Xshare:off -m main` will print the expected warning, `java -Xshare:on -m main` will not.

Another effect of the change to note is that incubator modules will now resolved by default when the initial module is the unnamed module. More explicitly, if you jlink to create a run-time image that contains a main module and an incubator module then `java -Xshare:off -version` will not resolve the incubator moduls (correct behaviour) but `java -Xshare:on` will resolve incubator modules (wrong behavior).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367685991

From alanb at openjdk.org  Sat Oct 21 08:54:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Oct 2023 08:54:35 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 20 Oct 2023 20:24:26 GMT, Calvin Cheung  wrote:

> I tried the above but got the following build error:
> 
> ```
> Optimizing the exploded image
> Error occurred during initialization of boot layer
> java.lang.NullPointerException
> ExplodedImageOptimize.gmk:39: recipe for target '/scratch/cccheung/ws/git/curr_jdk/build/mywork-debug/jdk/_optimize_image_exec.marker' failed
> ```

I checked tier1 with this change and don't see an issue, is it possible that something was left over in your env?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1367692383

From alanb at openjdk.org  Sat Oct 21 09:13:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Oct 2023 09:13:27 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal
In-Reply-To: 
References: 
Message-ID: 

On Sat, 21 Oct 2023 00:56:21 GMT, Joe Darcy  wrote:

> Add informative notes to BigInteger and BigDecimal about possible running times, etc.

The wording looks okay to me and I expect it will appear as an API note in BigInteger.

However, for BigDecimal I suspect the h2 headings (for the next heading and the existing heading for IEEE 754 Decimal Arithmetic) means they won't look like they are part of the API note, instead they will look like new sections after the API note. Do you see what I mean in the generated javadoc?

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16298#pullrequestreview-1691219200

From dnsimon at openjdk.org  Sat Oct 21 10:56:01 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 21 Oct 2023 10:56:01 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: 
References: 
Message-ID: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.

Doug Simon has updated the pull request with a new target base 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 tag 'jdk-22+18' into JDK-8318027_rename
   
   Added tag jdk-22+18 for changeset 3105538d
 - rename jdk.compiler.graal to jdk.graal.compiler
 - re-fix since tags to reflect current JDK release
 - fix copyright dates and @since tags to reflect history
 - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16189/files
  - new: https://git.openjdk.org/jdk/pull/16189/files/193e22a6..3014f40f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16189&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16189&range=02-03

  Stats: 11380 lines in 399 files changed: 5944 ins; 1943 del; 3493 mod
  Patch: https://git.openjdk.org/jdk/pull/16189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16189/head:pull/16189

PR: https://git.openjdk.org/jdk/pull/16189

From dnsimon at openjdk.org  Sat Oct 21 11:35:36 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 21 Oct 2023 11:35:36 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
References: 
 <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
Message-ID: 

On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>> 
>> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186
>
> Doug Simon has updated the pull request with a new target base 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 tag 'jdk-22+18' into JDK-8318027_rename
>    
>    Added tag jdk-22+18 for changeset 3105538d
>  - rename jdk.compiler.graal to jdk.graal.compiler
>  - re-fix since tags to reflect current JDK release
>  - fix copyright dates and @since tags to reflect history
>  - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

Based on external discussion, agreement has been reached to rename to `jdk.graal.compiler` instead of `jdk.compiler.graal`.
Not only does this avoid the confusion with `jdk.compiler` pointed out by @jonathan-gibbons but it also establishes the namespace `jdk.graal` for Graal subprojects.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1773764186

From duke at openjdk.org  Sat Oct 21 11:59:40 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 21 Oct 2023 11:59:40 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
 
 
Message-ID: <0ZOP9qTBB96gh4159fZitWZDXWAw7f4EU-duUci-vUY=.e9fad84d-3f6b-4df6-927a-0c719c4e0612@github.com>

On Thu, 19 Oct 2023 11:58:26 GMT, Claes Redestad  wrote:

>> @cl4es 
>> 
>>> Good, narrows it down to what's going on in `prepend(long, byte[], String)`. Might boil down to `System.arraycopy`. This method might not be optimized for tiny arrays on all platforms. Specializing for single-char case:
>>> 
>>> ```java
>>> diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
>>> index 9b19d7e2ac1..6eb70925dab 100644
>>> --- a/src/java.base/share/classes/java/lang/String.java
>>> +++ b/src/java.base/share/classes/java/lang/String.java
>>> @@ -4723,7 +4723,11 @@ static void repeatCopyRest(byte[] buffer, int offset, int limit, int copied) {
>>>       */
>>>      void getBytes(byte[] dst, int dstBegin, byte coder) {
>>>          if (coder() == coder) {
>>> -            System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
>>> +            if (value.length == 1) {
>>> +                dst[(dstBegin << coder)] = value[0];
>>> +            } else {
>>> +                System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
>>> +            }
>>>          } else {    // this.coder == LATIN && coder == UTF16
>>>              StringLatin1.inflate(value, 0, dst, dstBegin, value.length);
>>>          }
>>> ```
>>> 
>>> .. seem to help the JIT do the right thing consistently, too:
>>> 
>>> ```
>>> Benchmark                                 Mode  Cnt   Score   Error  Units
>>> BigDecimals.testSmallToEngineeringString  avgt   50  11,757 ? 0,480  ns/op
>>> ```
>> 
>> In addition to #16244, will you submit a PR for this?
>
>> In addition to #16244, will you submit a PR for this?
> 
> Once both #16244 and this has been integrated I want to revisit this. The effect of changing `getBytes(byte[], int, byte)` might have disappeared with #16244 since it better guarantees the JIT will constant fold the prefixes thoroughly. We've observed related issues with System.arraycopy, however, see https://bugs.openjdk.org/browse/JDK-8295496 - so I want to evaluate a few different options here, time allowing.

@cl4es I found that StringConcatFactory.makeConcatWithConstants will become slower when using recipe("\1.\1", long.class, long.class). If we treat the prefix of length 1 as char, it will become faster.

In this branch https://github.com/wenshao/jdk/tree/optim_decimal_to_string_x2 , if we remove the code that treats the prefix of length 1 as char in the preparer(String prefix, Class cl) method, it will become slower.


package java.lang.invoke;

class StringConcatFactory {
    static MethodHandle prepender(String prefix, Class cl) {
        if (prefix == null || prefix.isEmpty()) {
            return noPrefixPrepender(cl);
        } else {
            // remove this will slower
            if (prefix.length() == 1
                    && (cl == char.class || cl == int.class || cl == long.class)) {
                char ch = prefix.charAt(0);
                MethodHandle prepend = JLA.stringConcatHelper(
                        "prepend",
                        methodType(long.class, long.class, byte[].class, cl, char.class)).rebind();
                return MethodHandles.insertArguments(prepend, 3, ch);
            }

            return MethodHandles.insertArguments(
                    prepender(cl), 3, prefix);
        }
    }
}


Here are the performance numbers running on the MaxBook M1 Max:


-Benchmark                             Mode  Cnt   Score   Error  Units (String prefix)
-BigDecimals.smallScale3ToPlainString  avgt   15  28.898 ? 0.527  ns/op

+Benchmark                             Mode  Cnt   Score   Error  Units (char prefix)
+BigDecimals.smallScale3ToPlainString  avgt   15  23.182 ? 0.477  ns/op


Maybe you should submit another PR to improve StringConcatFactory.makeConcatWithConstants

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1773768539

From jvernee at openjdk.org  Sat Oct 21 12:04:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 21 Oct 2023 12:04:10 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v11]
In-Reply-To: 
References: 
Message-ID: <2mpVRiA1idUeB0AN8eAtghk_sGFu90tZyTvpYOPaBq4=.72ab5bb9-3095-4352-9aa6-9e59151e482e@github.com>

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee 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 branch 'master' into AllowHeapNoLock
 - bump up argument counts in TestLargeStub to their maximum
 - s390 updates
 - add stub size stress test for allowHeap
 - RISC-V impl
 - remove leftover debug log line
 - add s390 support
 - add PPC impl
 - add missing file
 - Add xor benchmark
 - ... and 36 more: https://git.openjdk.org/jdk/compare/a876beb6...2e00beff

-------------

Changes: https://git.openjdk.org/jdk/pull/16201/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=10
  Stats: 2699 lines in 74 files changed: 1712 ins; 692 del; 295 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From duke at openjdk.org  Sun Oct 22 02:53:11 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 22 Oct 2023 02:53:11 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v11]
In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
Message-ID: 

> I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them.
> 
> this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster.
> Please review and don't hesitate to critique my approach and patch.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  reduce duplicate code & code format & refactor benchmark case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16006/files
  - new: https://git.openjdk.org/jdk/pull/16006/files/d5cbd7e9..51b1041c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=09-10

  Stats: 250 lines in 2 files changed: 135 ins; 42 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/16006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006

PR: https://git.openjdk.org/jdk/pull/16006

From duke at openjdk.org  Sun Oct 22 05:59:34 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 22 Oct 2023 05:59:34 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: <0H6aE9gGK6DYTLUiCslROSDHzE6g8jduLBUm5m3JUls=.2b6e64c5-1fd5-416f-9a48-b113dfbea09f@github.com>
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
 <0H6aE9gGK6DYTLUiCslROSDHzE6g8jduLBUm5m3JUls=.2b6e64c5-1fd5-416f-9a48-b113dfbea09f@github.com>
Message-ID: 

On Thu, 19 Oct 2023 10:22:19 GMT, Raffaello Giulietti  wrote:

>> I've opened up #16244 for review - thanks for helping with analysis and verification.
>
> @cl4es @wenshao I'd like to review the mathematical aspects of these changes once the refactorings with string concatenations have stabilized enough to your satisfaction.
> 
> Please ping me here when no more such work is planned.
> TIA

@rgiulietti It is currently a stable version, please help me start the review.

Here are the performance numbers running on the MaxBook M1 Pro:


-Benchmark                                   Mode  Cnt    Score   Error  Units (baseline)
-BigDecimals.hugeEngineeringToString         avgt   15  199.683 ? 7.457  ns/op
-BigDecimals.hugeLayoutCharsToString         avgt   15  205.366 ? 2.673  ns/op
-BigDecimals.hugePlainToString               avgt   15  219.066 ? 3.334  ns/op
-BigDecimals.largeScale2EngineeringToString  avgt   15   55.303 ? 0.606  ns/op
-BigDecimals.largeScale2LayoutCharsToString  avgt   15   55.284 ? 0.512  ns/op
-BigDecimals.largeScale2PlainToString        avgt   15   22.836 ? 0.128  ns/op
-BigDecimals.largeScale3EngineeringToString  avgt   15   57.332 ? 0.851  ns/op
-BigDecimals.largeScale3LayoutCharsToString  avgt   15   57.535 ? 1.221  ns/op
-BigDecimals.largeScale3PlainToString        avgt   15   23.967 ? 0.055  ns/op
-BigDecimals.smallScale2EngineeringToString  avgt   15   17.063 ? 0.444  ns/op
-BigDecimals.smallScale2LayoutCharsToString  avgt   15   16.999 ? 0.072  ns/op
-BigDecimals.smallScale2PlainToString        avgt   15   24.069 ? 0.511  ns/op
-BigDecimals.smallScale3EngineeringToString  avgt   15   53.697 ? 0.872  ns/op
-BigDecimals.smallScale3LayoutCharsToString  avgt   15   53.754 ? 1.990  ns/op
-BigDecimals.smallScale3PlainToString        avgt   15   24.596 ? 0.100  ns/op

+Benchmark                                   Mode  Cnt    Score   Error  Units (51b1041)
+BigDecimals.hugeEngineeringToString         avgt   15  194.288 ? 7.294  ns/op (+2.78)
+BigDecimals.hugeLayoutCharsToString         avgt   15  192.121 ? 2.079  ns/op (+6.90)
+BigDecimals.hugePlainToString               avgt   15  201.692 ? 4.527  ns/op (+8.62)
+BigDecimals.largeScale2EngineeringToString  avgt   15   20.128 ? 0.266  ns/op (+174.76)
+BigDecimals.largeScale2LayoutCharsToString  avgt   15   20.681 ? 0.508  ns/op (+167.32)
+BigDecimals.largeScale2PlainToString        avgt   15   19.950 ? 0.273  ns/op (+14.47)
+BigDecimals.largeScale3EngineeringToString  avgt   15   23.564 ? 0.542  ns/op (+143.31)
+BigDecimals.largeScale3LayoutCharsToString  avgt   15   23.424 ? 0.057  ns/op (+145.63)
+BigDecimals.largeScale3PlainToString        avgt   15   22.991 ? 0.048  ns/op (+4.25)
+BigDecimals.smallScale2EngineeringToString  avgt   15   11.641 ? 0.181  ns/op (+46.58)
+BigDecimals.smallScale2LayoutCharsToString  avgt   15   11.589 ? 0.031  ns/op (+46.69)
+BigDecimals.smallScale2PlainToString        avgt   15   11.594 ? 0.032  ns/op (+107.60)
+BigDecimals.smallScale3EngineeringToString  avgt   15   24.684 ? 0.313  ns/op (+117.54)
+BigDecimals.smallScale3LayoutCharsToString  avgt   15   25.058 ? 0.151  ns/op (+114.52)
+BigDecimals.smallScale3PlainToString        avgt   15   24.194 ? 0.217  ns/op (+1.67)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1774003635

From mli at openjdk.org  Sun Oct 22 10:52:39 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sun, 22 Oct 2023 10:52:39 GMT
Subject: RFR: 8317846: Typo in API documentation of classes IdentityHashMap
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 05:29:22 GMT, ANUPAM DEV  wrote:

>> Hello,
>> 
>> I have fixed the typo in the comment for the constructor IdentityHashMap(Map m)
>> 
>> before: Constructs a new identity hash map containing the keys-value mappings in the specified map.
>> after: Constructs a new identity hash map containing the key-value mappings in the specified map.
>> 
>> Please review the change.
>> 
>> Regards,
>> Anupam
>
> ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted the Copyright year to 2022

trivial change, LGTM

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16134#pullrequestreview-1691411894

From mli at openjdk.org  Sun Oct 22 11:13:38 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sun, 22 Oct 2023 11:13:38 GMT
Subject: RFR: 8317868: Add @sealedGraph to MethodHandleDesc and descendants
 [v2]
In-Reply-To: 
References: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 11:18:41 GMT, Per Minborg  wrote:

>> This PR proposes to add  @sealedGraph to MethodHandleDesc and descendants.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Revoke change in DMHD

Marked as reviewed by mli (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16137#pullrequestreview-1691414926

From mli at openjdk.org  Sun Oct 22 11:25:30 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sun, 22 Oct 2023 11:25:30 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
References: 
 <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
Message-ID: 

On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>> 
>> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186
>
> Doug Simon has updated the pull request with a new target base 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 tag 'jdk-22+18' into JDK-8318027_rename
>    
>    Added tag jdk-22+18 for changeset 3105538d
>  - rename jdk.compiler.graal to jdk.graal.compiler
>  - re-fix since tags to reflect current JDK release
>  - fix copyright dates and @since tags to reflect history
>  - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

Marked as reviewed by mli (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16189#pullrequestreview-1691416502

From rgiulietti at openjdk.org  Sun Oct 22 11:27:40 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 22 Oct 2023 11:27:40 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal
In-Reply-To: 
References: 
Message-ID: 

On Sat, 21 Oct 2023 00:56:21 GMT, Joe Darcy  wrote:

> Add informative notes to BigInteger and BigDecimal about possible running times, etc.

src/java.base/share/classes/java/math/BigDecimal.java line 310:

> 308:  * time of operations can screen out {@code BigDecimal} values with
> 309:  * unscaled values or scales above a chosen magnitude.
> 310:  *

A paragraph about memory consumption is perhaps worthwhile as well.

src/java.base/share/classes/java/math/BigInteger.java line 127:

> 125:  * the input. For example, a method like {@link intValue()} would be
> 126:  * expected to run in O(1), that is constant time, since with
> 127:  * the current internal presentation only a fixed-size component of

Suggestion:

 * the current internal representation only a fixed-size component of

src/java.base/share/classes/java/math/BigInteger.java line 152:

> 150:  * time of operations can screen out {@code BigInteger} values above a
> 151:  * chosen magnitude.
> 152:  *

This explains the execution time characteristics but not the memory consumption aspects of the class.
I think that a couple of sentences about them would make this note more complete.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1367887343
PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1367886201
PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1367886932

From mli at openjdk.org  Sun Oct 22 11:40:41 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sun, 22 Oct 2023 11:40:41 GMT
Subject: RFR: 8318569: Add getter methods for Locale and Patterns in
 ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: 

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato  wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

LGTM

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16293#pullrequestreview-1691418437

From lbourges at openjdk.org  Sun Oct 22 14:57:56 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 22 Oct 2023 14:57:56 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v10]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <4igD43IdIHylAPE8CQ69rnIYpP4w1jYhrgqQTcTCXv4=.83c916bc-7fbf-4318-95d2-e2b4f195924e@github.com>

> * improved  mixed insertion sort (makes whole sorting faster)
> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
> * improved merging sort for almost sorted data
> * optimized parallel sorting
> * improved step for pivot candidates and pivot partitioning
> * extended existing tests
> * added benchmarking JMH tests
> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Laurent Bourg?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
  * Optimized mixed insertion sort
  * Optimized insertion sort
  * Optimized Radix sort
  * Updated microbenchmark

-------------

Changes: https://git.openjdk.org/jdk/pull/13568/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=09
  Stats: 4477 lines in 4 files changed: 1713 ins; 1404 del; 1360 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From duke at openjdk.org  Sun Oct 22 16:00:32 2023
From: duke at openjdk.org (iaroslavski)
Date: Sun, 22 Oct 2023 16:00:32 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v9]
In-Reply-To: 
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
 <8wFp2rFtTWDGTQ4AKB4QYNjb0eJrg6aDznXP3p8agKE=.a0b699ac-f725-4bfd-9d07-bc7ace20b0a0@github.com>
 
 <4gJ8559jIkiqFQNZHixQ1omfMjW7kKRtjaYFc92Xb90=.b64864d7-a56e-40bd-9581-d5abf97cb7e5@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 16:33:56 GMT, Paul Sandoz  wrote:

> > Hi Paul (@PaulSandoz), Alan (@AlanBateman), Any update? Do you agree with Radix sort in parallel case only?
> 
> I think its definitely a better fit, but another aspect of my previous comment was wondering if we need a radix sort if the vectorized quicksort implementation is fast enough. IMO we need to compare performance results with the vectorized quick sort, and be aware of future enhancements to that.

Hi Paul (@PaulSandoz), Alan (@AlanBateman),

PR with AVX512 improvements has been integrated and I compared current JDK sorting
with my suggested changes. We agreeded to invoke Radix sort in parallel sorting only,
but sequentiual soring (even without Radix sort) shows upto ~ 5-20% speedup
as shown in the performance data below.

Arrays.sort benchmark | Data Type | Array Size | Baseline (us/op) | New version (us/op) | Speedup
-- | -- | -- | -- | -- | --
ArraysSort.intSort |   RANDOM |     600 |      9,016 |      8,426 |  1.07 
ArraysSort.intSort |   RANDOM |    9000 |    526,099 |    499,479 |  1.05 
ArraysSort.intSort |   RANDOM |   20000 |   1283,544 |   1194,464 |  1.07 
ArraysSort.intSort |   RANDOM |  400000 |  32547,730 |  30314,660 |  1.07 
ArraysSort.intSort |   RANDOM | 3000000 | 287803,223 | 274460,275 |  1.05 
ArraysSort.intSort | REPEATED |     600 |      2,041 |      1,877 |  1.09 
ArraysSort.intSort | REPEATED |    9000 |    101,790 |     94,416 |  1.08 
ArraysSort.intSort | REPEATED |   20000 |    262,945 |    210,241 |  1.25 
ArraysSort.intSort | REPEATED |  400000 |   4560,917 |   4242,648 |  1.08 
ArraysSort.intSort | REPEATED | 3000000 |  36925,218 |  33656,517 |  1.10 
ArraysSort.intSort |  STAGGER |     600 |      9,348 |      3,711 |  2.52 
ArraysSort.intSort |  STAGGER |    9000 |     54,833 |     50,308 |  1.09 
ArraysSort.intSort |  STAGGER |   20000 |    124,794 |    110,447 |  1.13 
ArraysSort.intSort |  STAGGER |  400000 |   2623,982 |   2325,099 |  1.13 
ArraysSort.intSort |  STAGGER | 3000000 |  19688,017 |  16812,050 |  1.17 
ArraysSort.intSort |  SHUFFLE |     600 |      5,361 |      4,960 |  1.08 
ArraysSort.intSort |  SHUFFLE |    9000 |    208,574 |    171,812 |  1.21 
ArraysSort.intSort |  SHUFFLE |   20000 |    442,811 |    401,294 |  1.10 
ArraysSort.intSort |  SHUFFLE |  400000 |  10048,756 |   9313,178 |  1.08 
ArraysSort.intSort |  SHUFFLE | 3000000 |  77659,359 |  65154,186 |  1.19 

Parallel soring (with Radix sort) shows upto x2.1-3.6 speedup,
please, see benchamrking data below.

Arrays.sort benchmark | Data Type | Array Size | Baseline (us/op) | New version (us/op) | Speedup
-- | -- | -- | -- | -- | --
ArraysSort.intParallelSort |   RANDOM |     600 |     9,036 |     8,350 | 1.08  
ArraysSort.intParallelSort |   RANDOM |    9000 |   366,551 |   126,962 | 2.89  
ArraysSort.intParallelSort |   RANDOM |   20000 |   497,725 |   193,564 | 2.57  
ArraysSort.intParallelSort |   RANDOM |  400000 |  8096,295 |  2711,692 | 2.99  
ArraysSort.intParallelSort |   RANDOM | 3000000 | 68663,019 | 19060,058 | 3.60  
ArraysSort.intParallelSort | REPEATED |     600 |     2,059 |     1,878 | 1.10  
ArraysSort.intParallelSort | REPEATED |    9000 |    80,267 |    70,176 | 1.14  
ArraysSort.intParallelSort | REPEATED |   20000 |   250,379 |   109,370 | 2.29  
ArraysSort.intParallelSort | REPEATED |  400000 |  4571,467 |  1469,696 | 3.11  
ArraysSort.intParallelSort | REPEATED | 3000000 | 30484,679 | 11636,387 | 2.62  
ArraysSort.intParallelSort |  STAGGER |     600 |     9,676 |     3,700 | 2.62  
ArraysSort.intParallelSort |  STAGGER |    9000 |    54,892 |    52,106 | 1.05  
ArraysSort.intParallelSort |  STAGGER |   20000 |   105,592 |    73,180 | 1.44  
ArraysSort.intParallelSort |  STAGGER |  400000 |  1766,893 |   765,052 | 2.31  
ArraysSort.intParallelSort |  STAGGER | 3000000 | 11912,261 |  6759,822 | 1.76  
ArraysSort.intParallelSort |  SHUFFLE |     600 |     5,417 |     4,974 | 1.09  
ArraysSort.intParallelSort |  SHUFFLE |    9000 |   121,579 |    71,555 | 1.70  
ArraysSort.intParallelSort |  SHUFFLE |   20000 |   236,334 |   111,430 | 2.12  
ArraysSort.intParallelSort |  SHUFFLE |  400000 |  3108,046 |  1075,329 | 2.89  
ArraysSort.intParallelSort |  SHUFFLE | 3000000 | 27130,857 | 11791,105 | 2.30  

New version is good enough: doesn't effect on memory usage for Arrays.osrt()
and shows the boost of performance on parallel sorting.

Paul, Alan,
Are you fine with this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1774130261

From lbourges at openjdk.org  Sun Oct 22 17:26:52 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 22 Oct 2023 17:26:52 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: 

> * improved  mixed insertion sort (makes whole sorting faster)
> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
> * improved merging sort for almost sorted data
> * optimized parallel sorting
> * improved step for pivot candidates and pivot partitioning
> * extended existing tests
> * added benchmarking JMH tests
> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  add @SuppressWarnings (serial)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13568/files
  - new: https://git.openjdk.org/jdk/pull/13568/files/13b1b1e9..4744a260

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=09-10

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From darcy at openjdk.org  Sun Oct 22 19:32:26 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 22 Oct 2023 19:32:26 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 22 Oct 2023 11:22:27 GMT, Raffaello Giulietti  wrote:

>> Add informative notes to BigInteger and BigDecimal about possible running times, etc.
>
> src/java.base/share/classes/java/math/BigInteger.java line 152:
> 
>> 150:  * time of operations can screen out {@code BigInteger} values above a
>> 151:  * chosen magnitude.
>> 152:  *
> 
> This explains the execution time characteristics but not the memory consumption aspects of the class.
> I think that a couple of sentences about them would make this note more complete.

A reasonable suggestion; I was considering mentioning memory usage in the initial version. I'll craft something brief for both classes on memory usage.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1367957742

From darcy at openjdk.org  Mon Oct 23 03:46:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Oct 2023 03:46:54 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v2]
In-Reply-To: 
References: 
Message-ID: 

> Add informative notes to BigInteger and BigDecimal about possible running times, etc.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16298/files
  - new: https://git.openjdk.org/jdk/pull/16298/files/c959f3b5..c12f9459

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16298&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16298&range=00-01

  Stats: 14 lines in 2 files changed: 9 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16298/head:pull/16298

PR: https://git.openjdk.org/jdk/pull/16298

From darcy at openjdk.org  Mon Oct 23 03:50:50 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Oct 2023 03:50:50 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v3]
In-Reply-To: 
References: 
Message-ID: 

> Add informative notes to BigInteger and BigDecimal about possible running times, etc.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16298/files
  - new: https://git.openjdk.org/jdk/pull/16298/files/c12f9459..956f66fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16298&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16298&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16298/head:pull/16298

PR: https://git.openjdk.org/jdk/pull/16298

From pminborg at openjdk.org  Mon Oct 23 06:19:39 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Oct 2023 06:19:39 GMT
Subject: Integrated: 8317868: Add @sealedGraph to MethodHandleDesc and
 descendants
In-Reply-To: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
References: <5ZQzsj-yq3_1YYxGKz5uFc9iBiUl9YKl3_15OM_-MVY=.de0a6e84-9b98-4cd9-a912-d1dfbba55c4c@github.com>
Message-ID: 

On Wed, 11 Oct 2023 07:45:17 GMT, Per Minborg  wrote:

> This PR proposes to add  @sealedGraph to MethodHandleDesc and descendants.

This pull request has now been integrated.

Changeset: ffadd635
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/ffadd635759d0898cd108f5fe5fe3a4a3de91763
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8317868: Add @sealedGraph to MethodHandleDesc and descendants

Reviewed-by: jvernee, mli

-------------

PR: https://git.openjdk.org/jdk/pull/16137

From jpai at openjdk.org  Mon Oct 23 06:29:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 06:29:35 GMT
Subject: RFR: 8317846: Typo in API documentation of classes IdentityHashMap
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 05:29:22 GMT, ANUPAM DEV  wrote:

>> Hello,
>> 
>> I have fixed the typo in the comment for the constructor IdentityHashMap(Map m)
>> 
>> before: Constructs a new identity hash map containing the keys-value mappings in the specified map.
>> after: Constructs a new identity hash map containing the key-value mappings in the specified map.
>> 
>> Please review the change.
>> 
>> Regards,
>> Anupam
>
> ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted the Copyright year to 2022

Given that the rest of the javadoc in this class uses the term `key-value` at various places, this indeed looks like a typo.

The change looks good to me.

Please update the copyright year on this file to:

> Copyright (c) 2000, 2023, Oracle ....

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16134#pullrequestreview-1691785082
PR Comment: https://git.openjdk.org/jdk/pull/16134#issuecomment-1774511647

From pminborg at openjdk.org  Mon Oct 23 06:39:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Oct 2023 06:39:35 GMT
Subject: RFR: 8317870: Add @sealedGraph to Thread.Builder
In-Reply-To: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>
References: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>
Message-ID: 

On Wed, 11 Oct 2023 07:52:54 GMT, Per Minborg  wrote:

> This PR proposes to Add @sealedGraph to `Thread.Builder`.

I will close this PR as the taglet was not deemed to be helpful here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16138#issuecomment-1774522674

From pminborg at openjdk.org  Mon Oct 23 06:39:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Oct 2023 06:39:35 GMT
Subject: Withdrawn: 8317870: Add @sealedGraph to Thread.Builder
In-Reply-To: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>
References: <_gSW8Pog3Q0V9cQ9h2vm1DPfexySsybKdtDDSAZifJU=.93bd2b55-b56d-450d-9b22-70d178e131e1@github.com>
Message-ID: 

On Wed, 11 Oct 2023 07:52:54 GMT, Per Minborg  wrote:

> This PR proposes to Add @sealedGraph to `Thread.Builder`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16138

From uschindler at openjdk.org  Mon Oct 23 08:20:56 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Mon, 23 Oct 2023 08:20:56 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 6 Oct 2023 16:26:42 GMT, Raffaello Giulietti  wrote:

>> See the [JBS issue](https://bugs.openjdk.org/browse/JDK-8317515) for the details.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using compareUnsigned() rather than open logic.

This caused issue sin Apache Lucene, as it should not chnge message as it was befor ethis change.

See https://bugs.openjdk.org/browse/JDK-8318646

src/java.base/share/classes/java/lang/Integer.java line 565:

> 563:         int len = s.length();
> 564:         if (len == 0) {
> 565:             throw new NumberFormatException("");

This caused a regression in Apache Lucene (see https://github.com/apache/lucene/issues/12708) and should be: `throw NumberFormatException.forInputString("", radix);`

src/java.base/share/classes/java/lang/Integer.java line 640:

> 638:          */
> 639:         if (beginIndex == endIndex) {
> 640:             throw new NumberFormatException("");

This caused a regression in Apache Lucene (see https://github.com/apache/lucene/issues/12708) and should be: `throw NumberFormatException.forInputString("", radix);`

src/java.base/share/classes/java/lang/Integer.java line 830:

> 828:          */
> 829:         if (beginIndex == endIndex) {
> 830:             throw new NumberFormatException("");

This caused a regression in Apache Lucene (see https://github.com/apache/lucene/issues/12708) and should be: `throw NumberFormatException.forInputString("", radix);`

src/java.base/share/classes/java/lang/Long.java line 595:

> 593:         int len = s.length();
> 594:         if (len == 0) {
> 595:             throw new NumberFormatException("");

This caused a regression in Apache Lucene (see https://github.com/apache/lucene/issues/12708) and should be: `throw NumberFormatException.forInputString("", radix);`

src/java.base/share/classes/java/lang/Long.java line 670:

> 668:          */
> 669:         if (beginIndex == endIndex) {
> 670:             throw new NumberFormatException("");

This caused a regression in Apache Lucene (see https://github.com/apache/lucene/issues/12708) and should be: `throw NumberFormatException.forInputString("", radix);`

-------------

PR Review: https://git.openjdk.org/jdk/pull/16050#pullrequestreview-1691955892
PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1368289384
PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1368289714
PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1368290255
PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1368290564
PR Review Comment: https://git.openjdk.org/jdk/pull/16050#discussion_r1368290726

From coffeys at openjdk.org  Mon Oct 23 09:14:06 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 23 Oct 2023 09:14:06 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v9]
In-Reply-To: 
References: 
Message-ID: <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Update code comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/d126c7f6..3635e542

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=07-08

  Stats: 17 lines in 1 file changed: 7 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From rgiulietti at openjdk.org  Mon Oct 23 09:52:39 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 23 Oct 2023 09:52:39 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 23 Oct 2023 08:17:43 GMT, Uwe Schindler  wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using compareUnsigned() rather than open logic.
>
> This caused issue sin Apache Lucene, as it should not chnge message as it was befor ethis change.
> 
> See https://bugs.openjdk.org/browse/JDK-8318646

@uschindler The spec of `parse[Int|Long]` is committed to throw particular exception types, but says nothing about the message content.
IMO, relying on exception messages should be considered as a last resort choice, as they can change.
 
However, I agree that this is an easy fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1774823680

From rgiulietti at openjdk.org  Mon Oct 23 09:58:36 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 23 Oct 2023 09:58:36 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 03:46:54 GMT, Joe Darcy  wrote:

>> Add informative notes to BigInteger and BigDecimal about possible running times, etc.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

src/java.base/share/classes/java/math/BigInteger.java line 127:

> 125:  * the input. For example, a method like {@link intValue()} would be
> 126:  * expected to run in O(1), that is constant time, since with
> 127:  * the current internal reprentation only a fixed-size component of

Suggestion:

 * the current internal representation only a fixed-size component of

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1368414023

From rgiulietti at openjdk.org  Mon Oct 23 09:58:37 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 23 Oct 2023 09:58:37 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 23 Oct 2023 09:55:16 GMT, Raffaello Giulietti  wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/java/math/BigInteger.java line 127:
> 
>> 125:  * the input. For example, a method like {@link intValue()} would be
>> 126:  * expected to run in O(1), that is constant time, since with
>> 127:  * the current internal reprentation only a fixed-size component of
> 
> Suggestion:
> 
>  * the current internal representation only a fixed-size component of

LGTM

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1368415466

From jpai at openjdk.org  Mon Oct 23 10:18:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 10:18:36 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v9]
In-Reply-To: <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
References: 
 <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
Message-ID: 

On Mon, 23 Oct 2023 09:14:06 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update code comments

Hello Sean, thank you for the updates. The fix now really boils down to fixing the `hashCode()` implementation of `java.util.zip.ZipFile$Source$Key` so that it honours the `equals()` and `hashCode()` contract which mandates that the `hashCode()` returned by instances which are `equals()` must be the same.

The change you have in the `Key` class now looks good to me.

Coming to the newly introduced `ZipSourceCache.java` test case, I went through it. What's being done in that test looks OK to me, but I felt that it's a bit too complex for what I think we should be testing here - asserting that `hashCode()` returned by `Key` instances are same if `Key` instances are `equals()`.

I decided to attempt a different way to test this and this is what the test looks like:


/*
 * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/* @test
 * @bug 8317678
 * @modules java.base/java.util.zip:open
 * @summary Fix up hashCode() for ZipFile.Source.Key
 * @run junit/othervm ZipSourceCache
 */

import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;
import java.nio.file.FileSystem;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.attribute.BasicFileAttributes;

import org.junit.jupiter.api.AfterAll;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;

public class ZipSourceCache {
    private static final String TEST_FILE_NAME = "foobar.zip";

    @BeforeAll
    public static void beforeAll() throws Exception {
        // create the file to run our test
        try (final FileOutputStream fos = new FileOutputStream(TEST_FILE_NAME)) {
            // no need to write anything to the file, just the presence of the file
            // is enough
        }
    }

    @AfterAll
    public static void afterAll() throws Exception {
        Files.deleteIfExists(Path.of(TEST_FILE_NAME));
    }

    /*
     * Verifies that instances of java.util.zip.ZipFile$Source$Key which are "equal()"
     * return back the same "hashCode()"
     */
    @Test
    public void testKeyEqualsHashCode() throws Exception {
        // create an instance of java.util.zip.ZipCoder for UTF-8 charset
        final Class zipCoderClass = Class.forName("java.util.zip.ZipCoder");
        final Method m = zipCoderClass.getDeclaredMethod("get", Charset.class);
        m.setAccessible(true);
        final Object utf8ZipCoder = m.invoke(null, StandardCharsets.UTF_8);


        // get the java.util.zip.ZipFile$Source$Key class
        final Class keyClass = Class.forName("java.util.zip.ZipFile$Source$Key");
        final Constructor ctr = keyClass.getConstructor(File.class, BasicFileAttributes.class,
                zipCoderClass);
        ctr.setAccessible(true);

        final File relFile = new File(TEST_FILE_NAME);
        final File absFile = new File(TEST_FILE_NAME).getAbsoluteFile();
        System.out.println("Running test on " + keyClass.getName() + " with relative File path "
                + relFile.getPath() + " and absolute File path " + absFile.getPath());
        // create an instance of java.util.zip.ZipFile$Source$Key passing it a relative file path
        // to "foobar.zip"
        final Object relKey = ctr.newInstance(relFile, getAttrs(relFile), utf8ZipCoder);
        System.out.println("relKey, hashCode = " + relKey.hashCode());

        // create an instance of java.util.zip.ZipFile$Source$Key passing it an absolute file path
        // to "foobar.zip"
        final Object absKey = ctr.newInstance(absFile, getAttrs(absFile), utf8ZipCoder);
        System.out.println("absKey, hashCode = " + absKey.hashCode());
        // these 2 Key instances, one created with a relative File path and other with a absolute
        // File path, to the same file, are expected to be "equal()"
        Assertions.assertTrue(absKey.equals(relKey), "Key instances were expected to be equal");
        // verify that the instances which are "equal()" return the same "hashCode()"
        Assertions.assertEquals(relKey.hashCode(), absKey.hashCode(), "Differing hashCode() for" +
                " Keys that were equal");
    }

    private static BasicFileAttributes getAttrs(final File file) throws IOException {
        final FileSystem fs = file.toPath().getFileSystem();
        return Files.readAttributes(fs.getPath(file.getPath()),
                BasicFileAttributes.class);
    }
}

All it does is asserts the `hashCode()` values of `Key` instances created out of a relative file and absolute file pointing to the same underlying file. This test consistently fails without your fix for the `Key` class and passes with your fix. I haven't run it on Windows, but I think it shouldn't be any different.

Do you think we could simplify the `ZipSourceCache.java` test in this PR to instead use this alternate approach or some form of it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1774868391

From uschindler at openjdk.org  Mon Oct 23 10:17:45 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Mon, 23 Oct 2023 10:17:45 GMT
Subject: RFR: 8317515: Unify the code of the parse*() families of methods
 in j.l.Integer and j.l.Long [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <6l8qMaFq-6bT4CFOZP4AFIemeMWU4_f_eqOr7R6FHWY=.59d36da5-eecd-41b9-be6e-4256f9489282@github.com>

On Mon, 23 Oct 2023 08:17:43 GMT, Uwe Schindler  wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using compareUnsigned() rather than open logic.
>
> This caused issue sin Apache Lucene, as it should not chnge message as it was befor ethis change.
> 
> See https://bugs.openjdk.org/browse/JDK-8318646

> @uschindler The spec of `parse[Int|Long]` is committed to throw particular exception types, but says nothing about the message content. IMO, relying on exception messages should be considered as a last resort choice, as they can change.
> 
> However, I agree that this is an easy fix.

Yes. I agree with this. 

The issue why I raised thus was that there may be code that relies on this. Although it is not part of spec, it might be a good idea to also keep code consistent and use a single way to instantiate the NumberFormatException.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16050#issuecomment-1774866080

From alanb at openjdk.org  Mon Oct 23 10:27:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Oct 2023 10:27:39 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v9]
In-Reply-To: <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
References: 
 <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
Message-ID: 

On Mon, 23 Oct 2023 09:14:06 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update code comments

The update to ZipFile.Key hashCode and the Key comments look good. I don't have time to study the test but I think Lance and Jai are looking at that.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16115#pullrequestreview-1692203826

From coffeys at openjdk.org  Mon Oct 23 10:41:41 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 23 Oct 2023 10:41:41 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v9]
In-Reply-To: <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
References: 
 <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
Message-ID: 

On Mon, 23 Oct 2023 09:14:06 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update code comments

Thanks for the test code suggestion Jai. I expanded test case coverage during development of the fix. While your suggested test case captures the core issue at hand, I think it misses a few important points that I captured in the current test. 

* ZipFile behaviour in the scenario where a file is re-opened and edited while references to the old ZipFile exist. A "invalid LOC header" needs to be thrown in cases where an old zip file mapping is still in use. An old iteration of this patch was going to remove use of lastModifiedTime and probably would have caused issue for some apps. This test case protects us in the future from that.

* the behaviour of incorrectly adding extra  mappings to our internal map has gone undetected for a few years. We've no test coverage in that area. The current test closely monitors numbers in that map now and allows for behavioural differences between Filesystems that support and don't support fileKey(). I think that protects us from future changes we might make in this area also.

I think your test will fail on windows. The rel and abs file Keys are still treated as different there (proposal to use getCanonicalPath seems too costly for performance)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1774912190

From mdonovan at openjdk.org  Mon Oct 23 11:18:49 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 23 Oct 2023 11:18:49 GMT
Subject: Integrated: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java
In-Reply-To: 
References: 
Message-ID: 

On Wed, 19 Jul 2023 12:03:40 GMT, Matthew Donovan  wrote:

> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.

This pull request has now been integrated.

Changeset: 704c6ea1
Author:    Matthew Donovan 
URL:       https://git.openjdk.org/jdk/commit/704c6ea16cabc217588f430fd3c302d6df5e9c19
Stats:     174 lines in 2 files changed: 59 ins; 93 del; 22 mod

8303525: Refactor/cleanup open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java

Reviewed-by: smarks, msheppar

-------------

PR: https://git.openjdk.org/jdk/pull/14932

From mcimadamore at openjdk.org  Mon Oct 23 11:20:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Oct 2023 11:20:43 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v11]
In-Reply-To: <2mpVRiA1idUeB0AN8eAtghk_sGFu90tZyTvpYOPaBq4=.72ab5bb9-3095-4352-9aa6-9e59151e482e@github.com>
References: 
 <2mpVRiA1idUeB0AN8eAtghk_sGFu90tZyTvpYOPaBq4=.72ab5bb9-3095-4352-9aa6-9e59151e482e@github.com>
Message-ID: <4sBQQH1b4696lwpEUQHfClgixwFfXnhoS-_ERbEwzS0=.1ae52882-4b5e-43a9-abbd-7cde799285d5@github.com>

On Sat, 21 Oct 2023 12:04:10 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee 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 branch 'master' into AllowHeapNoLock
>  - bump up argument counts in TestLargeStub to their maximum
>  - s390 updates
>  - add stub size stress test for allowHeap
>  - RISC-V impl
>  - remove leftover debug log line
>  - add s390 support
>  - add PPC impl
>  - add missing file
>  - Add xor benchmark
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/a876beb6...2e00beff

Looking more holistically at the Linker javadoc, there seems to be something missing in that we never say that passing heap segments to downcall is not supported? We have clarified the documentation w.r.t. by-value structs here:

https://github.com/openjdk/panama-foreign/pull/881

But I can't find anything for by-reference structs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1774971391

From jvernee at openjdk.org  Mon Oct 23 11:32:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Oct 2023 11:32:35 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v11]
In-Reply-To: <2mpVRiA1idUeB0AN8eAtghk_sGFu90tZyTvpYOPaBq4=.72ab5bb9-3095-4352-9aa6-9e59151e482e@github.com>
References: 
 <2mpVRiA1idUeB0AN8eAtghk_sGFu90tZyTvpYOPaBq4=.72ab5bb9-3095-4352-9aa6-9e59151e482e@github.com>
Message-ID: 

On Sat, 21 Oct 2023 12:04:10 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee 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 branch 'master' into AllowHeapNoLock
>  - bump up argument counts in TestLargeStub to their maximum
>  - s390 updates
>  - add stub size stress test for allowHeap
>  - RISC-V impl
>  - remove leftover debug log line
>  - add s390 support
>  - add PPC impl
>  - add missing file
>  - Add xor benchmark
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/a876beb6...2e00beff

> Looking more holistically at the Linker javadoc, there seems to be something missing in that we never say that passing heap segments to downcall is not supported? We have clarified the documentation w.r.t. by-value structs here:
> 
> [openjdk/panama-foreign#881](https://github.com/openjdk/panama-foreign/pull/881)
> 
> But I can't find anything for by-reference structs.

We added the check as part of: https://github.com/openjdk/panama-foreign/pull/737 I don't see any linker doc update there. I don't think we have anything. We could add a line to `donwcallHandle` that says that the returned handle throws an `IllegalArgumentException` if a heap segment is passed, unless heap segments are explicitly allowed through the `critical(true)` option.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1774989773

From mcimadamore at openjdk.org  Mon Oct 23 11:38:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Oct 2023 11:38:36 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v11]
In-Reply-To: 
References: 
 <2mpVRiA1idUeB0AN8eAtghk_sGFu90tZyTvpYOPaBq4=.72ab5bb9-3095-4352-9aa6-9e59151e482e@github.com>
 
Message-ID: 

On Mon, 23 Oct 2023 11:29:28 GMT, Jorn Vernee  wrote:

> We could add a line to `donwcallHandle` that says that the returned handle throws an `IllegalArgumentException` if a heap segment is passed, unless heap segments are explicitly allowed through the `critical(true)` option.

Something like that would be ok, yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1774999918

From duke at openjdk.org  Mon Oct 23 11:53:41 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 23 Oct 2023 11:53:41 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
 
 
Message-ID: 

On Thu, 19 Oct 2023 11:58:26 GMT, Claes Redestad  wrote:

>> @cl4es 
>> 
>>> Good, narrows it down to what's going on in `prepend(long, byte[], String)`. Might boil down to `System.arraycopy`. This method might not be optimized for tiny arrays on all platforms. Specializing for single-char case:
>>> 
>>> ```java
>>> diff --git a/src/java.base/share/classes/java/lang/String.java b/src/java.base/share/classes/java/lang/String.java
>>> index 9b19d7e2ac1..6eb70925dab 100644
>>> --- a/src/java.base/share/classes/java/lang/String.java
>>> +++ b/src/java.base/share/classes/java/lang/String.java
>>> @@ -4723,7 +4723,11 @@ static void repeatCopyRest(byte[] buffer, int offset, int limit, int copied) {
>>>       */
>>>      void getBytes(byte[] dst, int dstBegin, byte coder) {
>>>          if (coder() == coder) {
>>> -            System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
>>> +            if (value.length == 1) {
>>> +                dst[(dstBegin << coder)] = value[0];
>>> +            } else {
>>> +                System.arraycopy(value, 0, dst, dstBegin << coder, value.length);
>>> +            }
>>>          } else {    // this.coder == LATIN && coder == UTF16
>>>              StringLatin1.inflate(value, 0, dst, dstBegin, value.length);
>>>          }
>>> ```
>>> 
>>> .. seem to help the JIT do the right thing consistently, too:
>>> 
>>> ```
>>> Benchmark                                 Mode  Cnt   Score   Error  Units
>>> BigDecimals.testSmallToEngineeringString  avgt   50  11,757 ? 0,480  ns/op
>>> ```
>> 
>> In addition to #16244, will you submit a PR for this?
>
>> In addition to #16244, will you submit a PR for this?
> 
> Once both #16244 and this has been integrated I want to revisit this. The effect of changing `getBytes(byte[], int, byte)` might have disappeared with #16244 since it better guarantees the JIT will constant fold the prefixes thoroughly. We've observed related issues with System.arraycopy, however, see https://bugs.openjdk.org/browse/JDK-8295496 - so I want to evaluate a few different options here, time allowing.

@cl4es @rgiulietti 

Can I add scale2 method to StringLatin1? Like this:


package java.lang;

class StringLatin1 {
    static String scale2(long value) {
        long valueAbs = Math.abs(value);
        long highInt = valueAbs / 100;
        byte[] buf = new byte[Long.stringSize(highInt) + (value < 0 ? 4 : 3)];
        int p = buf.length - 2;
        writeDigitPair(buf, p, (int) (valueAbs % 100));
        buf[--p] = '.';
        getChars(highInt, p, buf);
        if (value < 0) {
            buf[0] = '-';
        }
        if (String.COMPACT_STRINGS) {
            return new String(buf, LATIN1);
        }
        return new String(inflate(buf, 0, buf.length), UTF16);
    }
}

class System {
	private static void setJavaLangAccess() {
		SharedSecrets.setJavaLangAccess(new JavaLangAccess() {
		    public String scale2(long i) {
                        return StringLatin1.scale2(i);
                    }
	        }
	}
}



I think this is more readable than using MethodHandle.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1775022048

From jpai at openjdk.org  Mon Oct 23 11:55:28 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 11:55:28 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v9]
In-Reply-To: 
References: 
 <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
 
Message-ID: 

On Mon, 23 Oct 2023 10:39:11 GMT, Sean Coffey  wrote:

> ZipFile behaviour in the scenario where a file is re-opened and edited
> while references to the old ZipFile exist. A "invalid LOC header" needs to be 
> thrown in cases where an old zip file mapping is still in use.

This PR doesn't do any source changes to introduce this behaviour. It instead just adds a test to assert this existing behaviour. So that's a good thing and testing this behaviour sounds fine to me.

>   the behaviour of incorrectly adding extra  mappings to our 
> internal map has gone undetected for a few years. 
> We've no test coverage in that area. The current test closely monitors 
> numbers in that map now and allows for behavioural differences between 
> Filesystems that support and don't support fileKey(). I think that protects us 
> from future changes we might make in this area also.

What you propose here sounds fine. The only part that I think will need a bit more experiments is to run something like a test-repeat of 50 or more to make sure that the number of jars opened when this test is running  doesn't get impacted by any unforeseen loading of classes or such (from the test framework for example) which could end up opening some more jar files which can then cause the shared static map to have a different count of jars than this test would expect. This is already a `/othervm` test so intereference is already reduced, but it would still be good to see if there's any scope of intermittent failures, by runinng a test-repeat job.

> I think your test will fail on windows. The rel and abs file Keys are still treated as different there (proposal to use getCanonicalPath seems too costly for performance)

You are right, I missed that part where the `equals()` may return false on Windows. So that part can't actually be asserted. The `hashCode()` too then needs to be asserted only if the instances are `equals()`.

> While your suggested test case captures the core issue at hand, I think it misses a few important points that I captured in the current test.

Thank you for the additional details explaining the rationale behind this test. What you propose sounds fine to me then. I've a few minor nits about this test, which I'll add inline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1775026122

From jpai at openjdk.org  Mon Oct 23 12:00:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 12:00:39 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v9]
In-Reply-To: <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
References: 
 <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
Message-ID: 

On Mon, 23 Oct 2023 09:14:06 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update code comments

test/jdk/java/util/zip/ZipFile/ZipSourceCache.java line 80:

> 78:         HashMap internalMap;
> 79:         int numSources;
> 80:         try (ZipFile zipFile = new ZipFile(ZIPFILE_NAME)) {

Do you think changing this to:

new ZipFile(relativeFile)

would be better and more clear about the intent? A few lines below, we use `new ZipFile(absoluteFile)` which I think is good because it makes it clear what is being done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1368547393

From jpai at openjdk.org  Mon Oct 23 12:06:31 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 12:06:31 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v9]
In-Reply-To: <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
References: 
 <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
Message-ID: <9O9mZijHA6iGi9g2Xe5sYVtLIIjxhpNOndSU2dXrXh4=.d456ae9f-7026-4d15-b3a0-13a2d138085d@github.com>

On Mon, 23 Oct 2023 09:14:06 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update code comments

test/jdk/java/util/zip/ZipFile/ZipSourceCache.java line 98:

> 96:             // ignore this part of test if file can't be updated (can't overwrite)
> 97:             if (createZipFile("differentContent")) {
> 98:                 ZipFile z = new ZipFile(ZIPFILE_NAME);

Same comment as a few lines above, maybe we should use `new ZipFile(relativeFile)` here to make the intention clear?

test/jdk/java/util/zip/ZipFile/ZipSourceCache.java line 108:

> 106:                 z.close();
> 107:                 assertEquals(--numSources, internalMap.size());
> 108:             }

I think adding a else block which prints that this part of the testing was skipped might provide some visibility on which parts of this test were run, if/when debugging this test on CI environments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1368553939
PR Review Comment: https://git.openjdk.org/jdk/pull/16115#discussion_r1368553078

From jpai at openjdk.org  Mon Oct 23 12:17:38 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 12:17:38 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v9]
In-Reply-To: <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
References: 
 <7LPtZhsnk2RF96Hl4ibhdgC52GHIPoId8-ZaQr9-gJw=.81f16710-8601-4ba9-9146-95f1f02f4bd0@github.com>
Message-ID: 

On Mon, 23 Oct 2023 09:14:06 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update code comments

Finally, now that this PR only fixes a bug in the hashCode() and doesn't introduce any performance changing characteristics to the code, do you think the micro benchmark test update being proposed in this PR is needed? I don't have too much knowledge of `jmh` and it's a bit unclear to me if the introduction of this new `@Benchmark` method would interefere with the numbers of the existing `@Benchmark` method. I can spend some time on reading up `jmh` and then reviewing this micro benchmark if you think adding that benchmark is useful in context of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1775060059

From alanb at openjdk.org  Mon Oct 23 12:21:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Oct 2023 12:21:31 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
References: 
 <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
Message-ID: <4GB8VGyiUeacXRu-XLjkdBQ31nDFKKH9lAaYRzl3viM=.19809082-209a-440c-b564-c2fbf0654d2b@github.com>

On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>> 
>> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186
>
> Doug Simon has updated the pull request with a new target base 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 tag 'jdk-22+18' into JDK-8318027_rename
>    
>    Added tag jdk-22+18 for changeset 3105538d
>  - rename jdk.compiler.graal to jdk.graal.compiler
>  - re-fix since tags to reflect current JDK release
>  - fix copyright dates and @since tags to reflect history
>  - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16189#pullrequestreview-1692387518

From jvernee at openjdk.org  Mon Oct 23 12:39:44 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 23 Oct 2023 12:39:44 GMT
Subject: RFR: 8316046: x64 platforms unecessarily save xmm16-31 when UseAVX >=
 3
Message-ID: 

See JBS issue. We don't need to save xmm16+ on x64 platforms (which are currently saved in FFM upcall stubs). This is achieved simply by adding these registers to the volatile register lists of both ABIs.

Related: https://github.com/openjdk/jdk/pull/15688

Testing: `jdk_foreign`

-------------

Commit messages:
 - don't save XMM16+ on Windows x64 and SysV

Changes: https://git.openjdk.org/jdk/pull/16307/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16307&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316046
  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16307.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16307/head:pull/16307

PR: https://git.openjdk.org/jdk/pull/16307

From coffeys at openjdk.org  Mon Oct 23 13:04:20 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 23 Oct 2023 13:04:20 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v10]
In-Reply-To: 
References: 
Message-ID: 

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate test review comments from Jai

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/3635e542..ff6c7d70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From mcimadamore at openjdk.org  Mon Oct 23 13:07:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 23 Oct 2023 13:07:27 GMT
Subject: RFR: 8316046: x64 platforms unecessarily save xmm16-31 when UseAVX
 >= 3
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 11:37:08 GMT, Jorn Vernee  wrote:

> See JBS issue. We don't need to save xmm16+ on x64 platforms (which are currently saved in FFM upcall stubs). This is achieved simply by adding these registers to the volatile register lists of both ABIs.
> 
> Related: https://github.com/openjdk/jdk/pull/15688
> 
> Testing: `jdk_foreign`

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16307#pullrequestreview-1692485832

From coffeys at openjdk.org  Mon Oct 23 13:08:33 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 23 Oct 2023 13:08:33 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 13:04:20 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate test review comments from Jai

Thanks for the review Jai. I've edited the test to use` ZipFile z = new ZipFile(relativeFile)` in both places. 

Regards the JMH benchmark, note that there is a significant performance gain for some environments with this patch. 2X improvement for filesystems that support fileKey() and deal with opening of a zip file twice (or more) but with different variants of path name. The benchmark update was useful for highlighting this. The existing ` src = files.get(key);` ZipFile code call is key to this improvement. Now that hashcode() is corrected, a new  pairing is avoided for the same zip file.

p.s. I've run test-repeat on mach5 for this new test a few times already. It was test repeat 20 or 30 IIRC. I'll bump it to 50 for last test round before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1775148314

From coffeys at openjdk.org  Mon Oct 23 13:11:41 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 23 Oct 2023 13:11:41 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 13:04:20 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate test review comments from Jai

meant to add - note that `createZipFile` already prints an error to standard err in the scenario where the zip file can't be opened for modification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1775156218

From dnsimon at openjdk.org  Mon Oct 23 13:18:49 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 23 Oct 2023 13:18:49 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
References: 
 <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
Message-ID: 

On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon  wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>> 
>> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186
>
> Doug Simon has updated the pull request with a new target base 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 tag 'jdk-22+18' into JDK-8318027_rename
>    
>    Added tag jdk-22+18 for changeset 3105538d
>  - rename jdk.compiler.graal to jdk.graal.compiler
>  - re-fix since tags to reflect current JDK release
>  - fix copyright dates and @since tags to reflect history
>  - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

Thanks for all the reviews and careful consideration on this naming change. It will have long term consequences so getting it right is important.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1775167880

From dnsimon at openjdk.org  Mon Oct 23 13:18:52 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 23 Oct 2023 13:18:52 GMT
Subject: Integrated: 8318027: Support alternative name to
 jdk.internal.vm.compiler
In-Reply-To: 
References: 
Message-ID: 

On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon  wrote:

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.
> 
> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186

This pull request has now been integrated.

Changeset: bd22d238
Author:    Doug Simon 
URL:       https://git.openjdk.org/jdk/commit/bd22d2381fa3f21b113d5b8ef95fe15cec50b066
Stats:     40 lines in 10 files changed: 0 ins; 14 del; 26 mod

8318027: Support alternative name to jdk.internal.vm.compiler

Reviewed-by: erikj, ihse, kvn, alanb, mli

-------------

PR: https://git.openjdk.org/jdk/pull/16189

From jpai at openjdk.org  Mon Oct 23 13:31:38 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 13:31:38 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 13:04:20 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate test review comments from Jai

Thank you for the updates, Sean. The test `ZipSourceCache` looks good to me in its current form. I have no other review comments except for the jmh benchmark. I'll approve this PR in its current form.

As for the jmh benchmark, the existing benchmark method has some informative inline comment explaining what it does. Perhaps we should have something similar for this new benchmark method explaining why it is there? It currently says "// Ensure that we only create ZipFile.Source.Key entry per unique zip file" which doesn't seem accurate considering that this is a benchmark method and doesn't have any verifications of Key counts. 

I'll read up a bit more about jmh tomorrow because I'm unsure how multiple `@Benchmark` methods within a single class are run and what all those annotations mean when it comes to state management and such. But you don't have to wait for my approval of that part. If anyone else approves this in the meantime, please go ahead with your integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1775197122

From jpai at openjdk.org  Mon Oct 23 13:34:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 13:34:34 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 13:04:20 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate test review comments from Jai

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16115#pullrequestreview-1692563327

From lancea at openjdk.org  Mon Oct 23 14:15:33 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 23 Oct 2023 14:15:33 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v10]
In-Reply-To: 
References: 
 
Message-ID: <45nLXzVuEf6kIHcs9hE-XllDUzOXQu-el9TrikLfdjM=.3389945f-249a-4631-94c5-1b336bab929b@github.com>

On Mon, 23 Oct 2023 13:04:20 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate test review comments from Jai

I think the latest changes are fine Sean

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16115#pullrequestreview-1692683963

From djelinski at openjdk.org  Mon Oct 23 14:29:28 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 23 Oct 2023 14:29:28 GMT
Subject: RFR: 8316046: x64 platforms unecessarily save xmm16-31 when UseAVX
 >= 3
In-Reply-To: 
References: 
Message-ID: <8-cRBtziN3qLKx91nH2ubUCe-K4OGVPPy7yI0izWewA=.3048bdb4-dd64-46c1-9f13-292296d2c4db@github.com>

On Mon, 23 Oct 2023 11:37:08 GMT, Jorn Vernee  wrote:

> See JBS issue. We don't need to save xmm16+ on x64 platforms (which are currently saved in FFM upcall stubs). This is achieved simply by adding these registers to the volatile register lists of both ABIs.
> 
> Related: https://github.com/openjdk/jdk/pull/15688
> 
> Testing: `jdk_foreign`

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16307#pullrequestreview-1692717476

From michael.x.mcmahon at oracle.com  Mon Oct 23 15:26:42 2023
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Mon, 23 Oct 2023 16:26:42 +0100
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/
 native GSS introduced by 8303809
In-Reply-To: <20231019220916.GG202255@twosigma.com>
References: <20231019220916.GG202255@twosigma.com>
Message-ID: 

Hi,

Thanks for bringing this to our attention. You are right that this is a 
misuse of the authentication cache in the case of Kerberos (Negotiate) 
authentication. Though that is not the case for other auth schemes, 
because normally what gets cached are credentials, rather than security 
tokens.

It makes no sense to cache GSS contexts either, outside the scope of any 
individual request (being authenticated through multiple 
request/responses). We don't need to cache it in this situation as it is 
already kept as a local variable in the HttpURLConnection impl class.

So, my first impression is that the fix here needs to disable the cache 
permanently for the Negotiate scheme, which is basically what the system 
property workaround is doing. But, we need to just be sure about that 
before we publish a PR.

Thanks,

Michael.

On 19/10/2023 23:09, Nico Williams wrote:
> # Crashes
>
> We recently upgrade to OpenJDK 17.0.8.1 and started observing crashes
> resulting from double-frees via `gss_delete_sec_context()`.
>
> Adding `-Djdk.spnego.cache=false` to our java invocations stops the
> crashes.  We believe this is due to a race condition that has long been
> in `HttpURLConnection` that was mostly harmless before but which with
> the addition of this commit:
>
>      16843770b5a 8303809: Dispose context in SPNEGO NegotiatorImpl
>
> became a use-after-free / double-free bug, leading to crashes.
>
> This happens with stock 17.0.8.1+1 from Adoptium.
>
> Attached is a reproducer, Test.java, which you can run like this:
>
>      $ # credendials are kinituser at jgssbug.twosigma.com, password password
>      $ #
>      $ "$JAVA_HOME/bin/java" \
>                -Dsun.security.jgss.native=true \
>                -Dsun.security.jgss.lib=/usr/lib/libgssapi_krb5.so \
>                Test.javahttps://kerberos.club/tmp/jgssbug.txt
>
> It doesn't crash every time, but it crashes often.
>
> A typical Java stack trace upon crashing looks like:
>
> j  sun.security.jgss.wrapper.GSSLibStub.deleteContext(J)J+0java.security.jgss at 17.0.8.1
> j  sun.security.jgss.wrapper.NativeGSSContext.dispose()V+76java.security.jgss at 17.0.8.1
> j  sun.security.jgss.GSSContextImpl.dispose()V+16java.security.jgss at 17.0.8.1
> j  sun.net.www.protocol.http.spnego.NegotiatorImpl.disposeContext()V+11java.security.jgss at 17.0.8.1
> J 4456 c1 sun.net.www.protocol.http.NegotiateAuthentication.disposeContext()Vjava.base at 17.0.8.1  (24 bytes) @ 0x00007f909dc33834 [0x00007f909dc337c0+0x0000000
> 000000074]
> j  sun.net.www.protocol.http.HttpURLConnection.getInputStream0()Ljava/io/InputStream;+1923java.base at 17.0.8.1
> j  sun.net.www.protocol.http.HttpURLConnection.getInputStream()Ljava/io/InputStream;+62java.base at 17.0.8.1
> j  sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream()Ljava/io/InputStream;+4java.base at 17.0.8.1
> j  Test.lambda$main$0()V+16
> j  Test$$Lambda$207+0x00007f9020144208.run()V+0
> j  java.lang.Thread.run()V+11java.base at 17.0.8.1
> v  ~StubRoutines::call_stub
>
> On the C side the crash typically happens in the allocator, typically in
> `free()`:
>
> #0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007fb6e1185535 in __GI_abort () at abort.c:79
> #2  0x00007fb6e11dc648 in __libc_message (action=action at entry=do_abort, fmt=fmt at entry=0x7fb6e12e62a0 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
> #3  0x00007fb6e11e2d6a in malloc_printerr (str=str at entry=0x7fb6e12e444e "free(): invalid pointer") at malloc.c:5359
> #4  0x00007fb6e11e459c in _int_free (av=, p=, have_lock=) at malloc.c:4180
> #5  0x00007fb582ba5b6d in krb5_free_address (context=context at entry=0x7fb5d80cbf60, val=0x7fb5d8000080) at kfree.c:62
> #6  0x00007fb582b93d9e in krb5_auth_con_free (context=context at entry=0x7fb5d80cbf60, auth_context=0x7fb5d80778a0) at auth_con.c:60
> #7  0x00007fb6440a3eec in krb5_gss_delete_sec_context (minor_status=0x7fb586868504, context_handle=0x7fb5d80e22d0, output_token=)
>      at delete_sec_context.c:77
> #8  0x00007fb6440964b0 in gssint_delete_internal_sec_context (minor_status=0x7fb586868504, mech_type=,
>      internal_ctx=internal_ctx at entry=0x7fb5d80e22d0, output_token=0x0) at g_glue.c:606
> #9  0x00007fb6440946dd in gss_delete_sec_context (minor_status=, context_handle=0x7fb5d80d2be8, output_token=)
>      at g_delete_sec_context.c:91
> #10 0x00007fb6440b8dfe in spnego_gss_delete_sec_context (minor_status=, context_handle=0x7fb5d807bd70, output_token=)
>      at spnego_mech.c:2161
> #11 0x00007fb6440964b0 in gssint_delete_internal_sec_context (minor_status=0x7fb586868504, mech_type=,
>      internal_ctx=internal_ctx at entry=0x7fb5d807bd70, output_token=0x0) at g_glue.c:606
> #12 0x00007fb6440946dd in gss_delete_sec_context (minor_status=, context_handle=0x7fb586868508, output_token=)
>      at g_delete_sec_context.c:91
> #13 0x00007fb6dc0559ff in Java_sun_security_jgss_wrapper_GSSLibStub_deleteContext () from /home/nico/tmp/jdk-17.0.8.1+1/lib/libj2gss.so
> #14 0x00007fb6c89a653a in ?? ()
> #15 0x0000000000000000 in ?? ()
>
> We've seen other variations, but always they can be traced to
> `HttpURLConnection`.
>
> (We do maintain local patches to OpenJDK JGSS code as well.  But that's
> a story for another time.  We do want to try again to upstream those
> patches.  Because we maintain such patches we developed an interim fix
> where we use `synchronized (lock)` in the JGSS `dispose()` methods and
> also `Reference.reachabilityFence(this)`, which worked to prevent the
> crashes, but that was before we learned that `-Djdk.spnego.cache=false`
> also works.  In any case, stock, unpatched OpenJDK 17.0.8.1 evinces this
> crasher.)
>
> # Root cause
>
> What 8303809 did was add calls to `dispose()` on `GSSContext` objects in
> NegotiatorImpl.java in a new method called `disposeContext()` that all
> HTTP authentication mechanisms now implement and which 8303809 also
> added.
>
> It took us a while to realize that the use of the `AuthCache` in
> `HttpURLConnection` implies concurrent access to the cached contexts via
> concurrent HTTP requests to the same origin.
>
> Concurrent access to and disposal of those context objects then leads to
> use-after-free / double-free errors when using sun.security.jgss.native.
>
> There's really several issues going on here:
>
>   - The `dispose()` methods in 17.x in the JGSS native C GSS bindings
>     clases are dangerous, as are finalizers generally (and these
>     `dispose()` methods are called from finalizers).
>
>     This is fixed in later OpenJDK releases by making use of `Cleaner`,
>     so there's not much more to say about this here.
>
>   - The `AuthCache` in `src/java.base/share/classes/sun/net/www/protocol/http/`
>     implies concurrency, and it's not clear that concurrency is allowable
>     in all cases.
>
>   - In the case of RFC 4559 "Negotiate" and GSS concurrency is very much
>     not permitted.  The GSS APIs can and should be thread-safe, but it is
>     still an error to invoke `initSecContext()` concurrently on the same
>     `GSSContext`!
>
>     GSS-API `initSecContext()`/`acceptSecContext()` are strictly
>     synchronous and serial.
>
>   - The `AuthCache` in `src/java.base/share/classes/sun/net/www/protocol/http/`
>     is likely a misfeature altogether, at least as far as sharing GSS-
>     like HTTP authentication mechanism contexts goes, and probably for
>     all other HTTP auth methods too.
>
>     It's not ok to take a reply token from a `WWW-Authenticate:` response
>     header and consume it together with a "context" created by a
>     unrelated request [to the same origin].
>
>     Every `WWW-Authenticate:`/`Authorization:` token must be matched to
>     the same [serial train of] request[s].
>
>     Thus if we have an RFC 4559 Negotiate exchange requiring 5 tokens, so
>     something like:
>
>     0: request..
>     1: 401 response w/ WWW-Authenticate: Negotiate
>     2: request w/ Authorization: Negotiate ...           (continue needed)
>     3: 200 response w/ WWW-Authenticate: Negotiate ...   (continue needed)
>     4: request w/ Authorization: Negotiate ...           (continue needed)
>     5: 200 response w/ WWW-Authenticate: Negotiate ...   (complete)
>
>     it would not be permissible for one of those reply tokens to be fed
>     to another request's GSSContext, nor would it be OK to have more than
>     one serial set of requests share the same GSSContext.
>
>   - The foregoing also applies to SCRAM, DIGEST-MD5, and just about any
>     and all HTTP authentication methods that I know.  I believe that
>     there is no value in caching HTTP authentication mechanism contexts
>     on the client side.
>
>     HTTP Authentication mechanisms like SCRAM and DIGEST-MD5 are
>     three-message mechanisms when counting the initial challenge:
>
>     0: request...
>     1: 401 response w/ WWW-Authenticate: DIGEST-MD5 
>     2: request w/ Authorization: DIGEST-MD5 ...
>     3: 200 w/ WWW-Authenticate: DIGEST-MD5 ... (complete)
>
>     There is no case in which caching and sharing a SCRAM or DIGEST-MD5
>     authentication context is useful because there is only one request/
>     response in which there is a context needed at all: between 2 and 3
>     inclusive in the above diagram.
>
>     Perhaps a single challenge can be shared with multiple subsequent
>     requests that will optimistically use SCRAM or DIGEST-MD5 knowing
>     that one response demanded it, but one should probably not do this,
>     though I could find nothing in RFC 5802 and 7677.
>
>   - Negotiate is really a bearer token system, albeit with the
>     possibility of using channel bindings.  Meaning we never use the
>     resulting GSSContext to encrypt or sign any part of the HTTP requests
>     and responses authenticated with that context.  Therefore there's
>     never any point in sharing a GSSContext in HTTP, not even once it's
>     fully-established -- there is no point in doing anything other than
>     disposing of a fully-established GSSContext in HTTP/Negotiate.
>
>     (Attempts to develop standards for encrypting/signing of HTTP
>     requests and responses at the HTTP layer rather than in TLS have
>     historically failed.  If one attempt to standardize such a thing
>     succeeds, _then_ there will be something worth sharing in a cache
>     with care to prevent use-after-dispose.)
>
>   - Because of the preceding, in HTTP/Negotiate it is desirable to "free"
>     any GSSContext immediately after it is complete.
>
>     This is presumably how you came to add the `disposeContext()` method:
>     because those cached contexts otherwise sit there using lots of
>     memory for no reason; someone must have noticed.  However, rather
>     than have an explicit `disposeContext()` these contexts should just
>     immediately be disposed of when complete or failed.
>
> # Possible fixes
>
>   - Backport the use of `Cleaner` in the JGSS `dispose()` methods.
>
>     This would not be very satisfying because the `HttpURLConnection`
>     `AuthCache` would remain buggy, but at least the JVM wouldn't crash.
>
>   - Default `jdk.spnego.cache` to `false`.
>
>   - Rethink or remove the `AuthCache` in `HttpURLConnection`.
>
>   - Something else?
>
> Thanks,
>
> Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vklang at openjdk.org  Mon Oct 23 15:36:56 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 23 Oct 2023 15:36:56 GMT
Subject: RFR: 8293713 : java/net/httpclient/BufferingSubscriberTest.java fails
 in timeout, blocked in submission publisher
Message-ID: 

Resolves a visibility issue in SubmissionPublisher by making the `waiter` member of BufferedSubscription *volatile*.

-------------

Commit messages:
 - Addresses JDK-8293713 by making the waiter thread member volatile

Changes: https://git.openjdk.org/jdk/pull/16313/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16313&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293713
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16313.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16313/head:pull/16313

PR: https://git.openjdk.org/jdk/pull/16313

From vklang at openjdk.org  Mon Oct 23 15:36:57 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 23 Oct 2023 15:36:57 GMT
Subject: RFR: 8293713 : java/net/httpclient/BufferingSubscriberTest.java
 fails in timeout, blocked in submission publisher
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 15:28:31 GMT, Viktor Klang  wrote:

> Resolves a visibility issue in SubmissionPublisher by making the `waiter` member of BufferedSubscription *volatile*.

Discussed this change with @DougLea

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16313#issuecomment-1775463988

From dl at openjdk.org  Mon Oct 23 16:01:38 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 23 Oct 2023 16:01:38 GMT
Subject: RFR: 8293713 : java/net/httpclient/BufferingSubscriberTest.java
 fails in timeout, blocked in submission publisher
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 15:28:31 GMT, Viktor Klang  wrote:

> Resolves a visibility issue in SubmissionPublisher by making the `waiter` member of BufferedSubscription *volatile*.

Yes, looks good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16313#issuecomment-1775517786

From egahlin at openjdk.org  Mon Oct 23 16:03:46 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 23 Oct 2023 16:03:46 GMT
Subject: Integrated: 8318124: JFR: Rewrite instrumentation to use Class-File
 API
In-Reply-To: 
References: 
Message-ID: 

On Sun, 15 Oct 2023 20:20:48 GMT, Erik Gahlin  wrote:

> Hi,
> 
> Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base.
> 
> To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. 
> 
> Testing: tier1-3 + jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 69c0ae23
Author:    Erik Gahlin 
URL:       https://git.openjdk.org/jdk/commit/69c0ae23a323dd547f53234848f32ed9ba41792b
Stats:     1178 lines in 12 files changed: 429 ins; 399 del; 350 mod

8318124: JFR: Rewrite instrumentation to use Class-File API

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.org/jdk/pull/16195

From bpb at openjdk.org  Mon Oct 23 16:08:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 23 Oct 2023 16:08:37 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 03:50:50 GMT, Joe Darcy  wrote:

>> Add informative notes to BigInteger and BigDecimal about possible running times, etc.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo.

I suggest taking a look at [JDK-8225458](https://bugs.openjdk.org/browse/JDK-8225458) while in this area.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16298#issuecomment-1775531298

From coffeys at openjdk.org  Mon Oct 23 16:12:45 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 23 Oct 2023 16:12:45 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v11]
In-Reply-To: 
References: 
Message-ID: 

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Update jmh test comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16115/files
  - new: https://git.openjdk.org/jdk/pull/16115/files/ff6c7d70..00f98786

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16115&range=09-10

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16115.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16115/head:pull/16115

PR: https://git.openjdk.org/jdk/pull/16115

From vklang at openjdk.org  Mon Oct 23 16:14:36 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 23 Oct 2023 16:14:36 GMT
Subject: RFR: 8293713 : java/net/httpclient/BufferingSubscriberTest.java
 fails in timeout, blocked in submission publisher
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 15:28:31 GMT, Viktor Klang  wrote:

> Resolves a visibility issue in SubmissionPublisher by making the `waiter` member of BufferedSubscription *volatile*.

@AlanBateman @stuart-marks Does any of you have any cycles to review this one-word PR? :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16313#issuecomment-1775543045

From jpai at openjdk.org  Mon Oct 23 16:38:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 23 Oct 2023 16:38:40 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v11]
In-Reply-To: 
References: 
 
Message-ID: <4Lum06dgpjDVDRekZHjhzjpdJeYmxLVb2xnYio_ooiA=.71716dda-8892-477b-b597-41bdff0c7557@github.com>

On Mon, 23 Oct 2023 16:12:45 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update jmh test comments

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16115#pullrequestreview-1693015714

From coffeys at openjdk.org  Mon Oct 23 17:15:49 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 23 Oct 2023 17:15:49 GMT
Subject: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 16:12:45 GMT, Sean Coffey  wrote:

>> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update jmh test comments

Thanks for the reviews - test-repeat=50 passed on mach5 for product/debug platforms Jai. All looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16115#issuecomment-1775646456

From coffeys at openjdk.org  Mon Oct 23 17:15:50 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 23 Oct 2023 17:15:50 GMT
Subject: Integrated: 8317678: Fix up hashCode() for ZipFile.Source.Key
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 08:32:28 GMT, Sean Coffey  wrote:

> Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source objects aren't created for the same zip file.

This pull request has now been integrated.

Changeset: 8d9a4b43
Author:    Sean Coffey 
URL:       https://git.openjdk.org/jdk/commit/8d9a4b43f4fff30fd217dab2c224e641cb913c18
Stats:     189 lines in 3 files changed: 188 ins; 0 del; 1 mod

8317678: Fix up hashCode() for ZipFile.Source.Key

Reviewed-by: lancea, alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/16115

From hboehm at google.com  Mon Oct 23 17:19:19 2023
From: hboehm at google.com (Hans Boehm)
Date: Mon, 23 Oct 2023 10:19:19 -0700
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal
In-Reply-To: 
References: 
 
Message-ID: 

Since I think this is about asymptotic complexity, which is determined by
behavior on large inputs, is there a reason to talk about switching to
other algorithms on smaller inputs? We certainly don't want to get into the
habit of listing "easy case" optimizations everywhere.

I'm unclear about the extent to which BigInteger is intended to provide
running times that depend only on the size of the inputs, or whether they
can vary with the actual bits in the input. Though hard to state precisely,
this does seem to matter to cryptographers. And it sometimes seems to
matter to others, since guarantees aimed at cryptographers can slow down
other code. Is it worth stating something more in this area?

On Sat, Oct 21, 2023 at 2:14?AM Alan Bateman  wrote:

> On Sat, 21 Oct 2023 00:56:21 GMT, Joe Darcy  wrote:
>
> > Add informative notes to BigInteger and BigDecimal about possible
> running times, etc.
>
> The wording looks okay to me and I expect it will appear as an API note in
> BigInteger.
>
> However, for BigDecimal I suspect the h2 headings (for the next heading
> and the existing heading for IEEE 754 Decimal Arithmetic) means they won't
> look like they are part of the API note, instead they will look like new
> sections after the API note. Do you see what I mean in the generated
> javadoc?
>
> -------------
>
> Marked as reviewed by alanb (Reviewer).
>
> PR Review:
> https://git.openjdk.org/jdk/pull/16298#pullrequestreview-1691219200
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jlu at openjdk.org  Mon Oct 23 17:22:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Oct 2023 17:22:45 GMT
Subject: RFR: 8318186: ChoiceFormat inconsistency between applyPattern() and
 setChoices()
Message-ID: 

Please review this PR which clarifies inconsistency between `ChoiceFormat::applyPattern` and `ChoiceFormat::setChoices`.

A `ChoiceFormat` is composed of limits and formats. `applyPattern()` will throw an exception if limits are not in ascending order, while `setChoices()` will not. This should be clarified in the specification of `applyPattern()`.

-------------

Commit messages:
 - change from impl spec to API spec
 - init

Changes: https://git.openjdk.org/jdk/pull/16317/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16317&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318186
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16317/head:pull/16317

PR: https://git.openjdk.org/jdk/pull/16317

From emcmanus at openjdk.org  Mon Oct 23 17:39:43 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Mon, 23 Oct 2023 17:39:43 GMT
Subject: RFR: 8318051: Duration.between uses exceptions for control flow
Message-ID: 

The existing logic uses nanosecond arithmetic to compute Duration.between. Since that can overflow for durations greater than 292 years, it has a try/catch that falls back to computing the seconds part and adjusting that for nanoseconds. However, exception handling is typically very expensive, so in cases like the one in the linked bug this method was a performance trap.

The new logic is essentially the old catch block. It needs a special case for when the number of seconds is 0, so it is slightly slower in that case. But in other cases it is probably somewhat faster, because it avoids a
[division](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/src/java.base/share/classes/java/time/Duration.java#L283) and associated mod.

The test coverage in
[`TCKDuration`](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/test/jdk/java/time/tck/java/time/TCKDuration.java#L780) is already very thorough so no new tests are needed.

-------------

Commit messages:
 - 8318051: Avoid try/catch in Duration.between

Changes: https://git.openjdk.org/jdk/pull/16318/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16318&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318051
  Stats: 32 lines in 1 file changed: 17 ins; 14 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16318/head:pull/16318

PR: https://git.openjdk.org/jdk/pull/16318

From naoto at openjdk.org  Mon Oct 23 18:04:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Oct 2023 18:04:28 GMT
Subject: RFR: 8318186: ChoiceFormat inconsistency between applyPattern()
 and setChoices()
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 17:16:08 GMT, Justin Lu  wrote:

> Please review this PR which clarifies inconsistency between `ChoiceFormat::applyPattern` and `ChoiceFormat::setChoices`.
> 
> A `ChoiceFormat` is composed of limits and formats. `applyPattern()` will throw an exception if limits are not in ascending order, while `setChoices()` will not. This should be clarified in the specification of `applyPattern()`.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16317#pullrequestreview-1693182794

From rgiulietti at openjdk.org  Mon Oct 23 18:10:45 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 23 Oct 2023 18:10:45 GMT
Subject: RFR: 8318646: Integer#parseInt("") throws empty NumberFormatException
 message
Message-ID: 

Please review this simple fix to restore the original exception message that existed before [16050](https://github.com/openjdk/jdk/pull/16050).

-------------

Commit messages:
 - Merge branch 'master' into 8318646
 - 8318646: Integer#parseInt("") throws empty NumberFormatException message
 - Appease jcheck.
 - JDK-8318476: Add resource consumption note to BigInteger and BigDecimal

Changes: https://git.openjdk.org/jdk/pull/16320/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16320&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318646
  Stats: 56 lines in 4 files changed: 48 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16320.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16320/head:pull/16320

PR: https://git.openjdk.org/jdk/pull/16320

From tom_L64 at hotmail.com  Mon Oct 23 18:26:11 2023
From: tom_L64 at hotmail.com (tom L)
Date: Mon, 23 Oct 2023 18:26:11 +0000
Subject: [JShell] SourceCodeAnalysis.CompletionInfo#source() can be null but
 the doc doesn't say anything about it
In-Reply-To: 
References: 
Message-ID: 

Hello,
I have a problem with JShell, I don?t know if it should go in this mailing list.
On JDK 21 (should be the same for any JDK version 9+), Windows 11, with this following code :
```
var jshell = JShell.create() ;
jshell.sourceCodeAnalysis().analyzeCompletion("println(").source() // null
```
this second line returns null, but the doc of SourceCodeAnalysis.CompletionInfo#source() says this:
```
Source code for the first Snippet of code input. For example, first statement, or first method declaration. Trailing semicolons will be added, as needed.
Returns:
the source of the first encountered Snippet
```
There is no mention that it can return null.
Yes it can makes sense to return null (well actually yesn?t since from what I?ve seen from the source code, it?s only null if it is incomplete, it?s not null even if it is unknown), since I gave an invalid snippet, but the doc should at least mention it.

Regards,
Tom.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rgiulietti at openjdk.org  Mon Oct 23 18:26:51 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 23 Oct 2023 18:26:51 GMT
Subject: RFR: 8318646: Integer#parseInt("") throws empty
 NumberFormatException message [v2]
In-Reply-To: 
References: 
Message-ID: <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>

> Please review this simple fix to restore the original exception message that existed before [16050](https://github.com/openjdk/jdk/pull/16050).

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Remove 2 extraneous files from commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16320/files
  - new: https://git.openjdk.org/jdk/pull/16320/files/ea60758b..5fff5adc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16320&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16320&range=00-01

  Stats: 50 lines in 2 files changed: 0 ins; 48 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16320.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16320/head:pull/16320

PR: https://git.openjdk.org/jdk/pull/16320

From redestad at openjdk.org  Mon Oct 23 18:44:31 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 23 Oct 2023 18:44:31 GMT
Subject: RFR: 8318646: Integer#parseInt("") throws empty
 NumberFormatException message [v2]
In-Reply-To: <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
References: 
 <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
Message-ID: 

On Mon, 23 Oct 2023 18:26:51 GMT, Raffaello Giulietti  wrote:

>> Please review this simple fix to restore the original exception message that existed before [16050](https://github.com/openjdk/jdk/pull/16050).
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove 2 extraneous files from commit

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16320#pullrequestreview-1693266200

From naoto at openjdk.org  Mon Oct 23 18:46:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Oct 2023 18:46:46 GMT
Subject: RFR: 8318487: Specification of the ListFormat.equals() method can be
 improved
Message-ID: 

Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.

-------------

Depends on: https://git.openjdk.org/jdk/pull/16293

Commit messages:
 - Fixing typo
 - Removed redundant wording
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/16321/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16321&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318487
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16321.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16321/head:pull/16321

PR: https://git.openjdk.org/jdk/pull/16321

From alanb at openjdk.org  Mon Oct 23 18:52:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Oct 2023 18:52:37 GMT
Subject: RFR: 8318646: Integer#parseInt("") throws empty
 NumberFormatException message [v2]
In-Reply-To: <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
References: 
 <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
Message-ID: 

On Mon, 23 Oct 2023 18:26:51 GMT, Raffaello Giulietti  wrote:

>> Please review this simple fix to restore the original exception message that existed before [16050](https://github.com/openjdk/jdk/pull/16050).
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove 2 extraneous files from commit

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16320#pullrequestreview-1693300484

From lancea at openjdk.org  Mon Oct 23 19:12:57 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 23 Oct 2023 19:12:57 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v8]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

Lance Andersen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8314891
 - Add missing space
 - Revamp isZip64ExtBlockSizeValid
 - Merge branch 'master' into JDK-8314891
 - Merge branch 'master' into JDK-8314891
 - Remove tab(s) from comment
 - Added additional tests, along with additional cleanup and refactoring
 - Clean up some minor formatting issues
 - Additional Zip64 extra header validation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/208a5ecc..255aec85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15650&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15650&range=06-07

  Stats: 75854 lines in 1953 files changed: 44906 ins; 19381 del; 11567 mod
  Patch: https://git.openjdk.org/jdk/pull/15650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15650/head:pull/15650

PR: https://git.openjdk.org/jdk/pull/15650

From redestad at openjdk.org  Mon Oct 23 19:24:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 23 Oct 2023 19:24:42 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v7]
In-Reply-To: 
References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com>
 
 
 
 
 
Message-ID: 

On Mon, 23 Oct 2023 11:50:02 GMT, Shaojin Wen  wrote:

> Can I add scale2 method to StringLatin1?

I'd strongly advice against this. 

> I think this is more readable than using MethodHandle.

View the `MethodHandle`s you add to use `StringConcatFactory` here as a temporary workaround before the code can be simplified to just regular string concatenation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16006#issuecomment-1775876481

From bpb at openjdk.org  Mon Oct 23 19:27:29 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 23 Oct 2023 19:27:29 GMT
Subject: RFR: 8318646: Integer#parseInt("") throws empty
 NumberFormatException message [v2]
In-Reply-To: <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
References: 
 <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
Message-ID: 

On Mon, 23 Oct 2023 18:26:51 GMT, Raffaello Giulietti  wrote:

>> Please review this simple fix to restore the original exception message that existed before [16050](https://github.com/openjdk/jdk/pull/16050).
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove 2 extraneous files from commit

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16320#pullrequestreview-1693378538

From darcy at openjdk.org  Mon Oct 23 19:48:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Oct 2023 19:48:28 GMT
Subject: RFR: 8318646: Integer#parseInt("") throws empty
 NumberFormatException message [v2]
In-Reply-To: <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
References: 
 <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
Message-ID: <8v8FtGRtsvyfgP1lGVxqLPCBmlxQn76W6GHYg0PwoMg=.b1cc8430-e3f5-4f03-858f-bc90f7325c88@github.com>

On Mon, 23 Oct 2023 18:26:51 GMT, Raffaello Giulietti  wrote:

>> Please review this simple fix to restore the original exception message that existed before [16050](https://github.com/openjdk/jdk/pull/16050).
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove 2 extraneous files from commit

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16320#pullrequestreview-1693407867

From bpb at openjdk.org  Mon Oct 23 20:09:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 23 Oct 2023 20:09:37 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 03:50:50 GMT, Joe Darcy  wrote:

>> Add informative notes to BigInteger and BigDecimal about possible running times, etc.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo.

src/java.base/share/classes/java/math/BigDecimal.java line 302:

> 300:  * scale. For example, an {@linkplain BigDecimal#multiply(BigDecimal)
> 301:  * exact multiply} of two {@code BigDecimal} values is subject to the
> 302:  * same {@linkplain BigInteger##algorithmicComplexity complexity

Does this link need two `##` or only one?

src/java.base/share/classes/java/math/BigInteger.java line 137:

> 135:  * results indicate a multiply algorithm for numbers using this
> 136:  * category of representation must run in at least
> 137:  * O(n log n). Common multiply

"Common _multiply_" or "Common _multiplication_"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1369211364
PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1369212528

From darcy at openjdk.org  Mon Oct 23 20:28:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Oct 2023 20:28:36 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 23 Oct 2023 20:05:50 GMT, Brian Burkhalter  wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 302:
> 
>> 300:  * scale. For example, an {@linkplain BigDecimal#multiply(BigDecimal)
>> 301:  * exact multiply} of two {@code BigDecimal} values is subject to the
>> 302:  * same {@linkplain BigInteger##algorithmicComplexity complexity
> 
> Does this link need two `##` or only one?

The "##" is used for HTML id's declared in the javadoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1369230076

From darcy at openjdk.org  Mon Oct 23 20:37:38 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Oct 2023 20:37:38 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 23 Oct 2023 20:07:07 GMT, Brian Burkhalter  wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo.
>
> src/java.base/share/classes/java/math/BigInteger.java line 137:
> 
>> 135:  * results indicate a multiply algorithm for numbers using this
>> 136:  * category of representation must run in at least
>> 137:  * O(n log n). Common multiply
> 
> "Common _multiply_" or "Common _multiplication_"?

Doing some grammar research ...

In English, using a noun as an adjective is called an "attributive noun," so the "multiplication" in "multiplication algorithm" would play that role.

Strictly speaking to "adjective-ifly" a verb would be to use a participle, one way to do that anyway -- "multiplying algorithm."

In any case, "multiply algorithm" reads okay to me, but I don't mind changing it to "multiplication algorithm."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1369237797

From darcy at openjdk.org  Mon Oct 23 20:47:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Oct 2023 20:47:42 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v4]
In-Reply-To: 
References: 
Message-ID: 

> Add informative notes to BigInteger and BigDecimal about possible running times, etc.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback, fix typos.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16298/files
  - new: https://git.openjdk.org/jdk/pull/16298/files/956f66fb..0a48c48f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16298&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16298&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16298/head:pull/16298

PR: https://git.openjdk.org/jdk/pull/16298

From joe.darcy at oracle.com  Mon Oct 23 21:00:38 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 23 Oct 2023 14:00:38 -0700
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal
In-Reply-To: 
References: 
 
 
Message-ID: <48dae74a-5da5-4020-9ab6-d530bc3540e7@oracle.com>

Hi Hans,

Giving some additional context, we'll occasionally get bug reports that 
amount to an observation equivalent to the following:

"I have two Big{Foo} variables and in a loop I assign larger and larger 
values to them. As the values get large, bigFoo1.add(bigFoo2) runs much 
faster than bigFoo1.multiply(bigFoo2). This seems wrong."

With additional knowledge of the algorithmic complexities of add and 
multiply for large values, the above is not a surprising result and the 
intention of the note is to share some additional context with the 
reader so they are not surprised by this result either. Additionally, 
the note does describe what the JDK implementation has done for some 
time, switching between algorithms based in input size, etc.

The new text in both classes appears under an apiNote, which means the 
next text is informative without being normative. Therefore, the JDK is 
not obliged to behave in the described way, but is free to do so.

The current BigInteger implementation is not written to be hardened 
against timing side-channel measurements.

Thanks,

-Joe

On 10/23/2023 10:19 AM, Hans Boehm wrote:
> Since I think this is about asymptotic complexity, which is determined 
> by behavior on large inputs, is there a reason to talk about switching 
> to other algorithms on smaller inputs? We certainly don't want to get 
> into the habit of listing "easy case" optimizations everywhere.
>
> I'm unclear about the extent to which BigInteger is intended to 
> provide running times that?depend only on the size of the inputs, or 
> whether they can vary with the actual bits in the input. Though hard 
> to state precisely, this does seem to matter to cryptographers. And it 
> sometimes seems to matter to others, since guarantees aimed?at 
> cryptographers can slow down other?code. Is it worth stating something 
> more in this area?
>
> On Sat, Oct 21, 2023 at 2:14?AM Alan Bateman  wrote:
>
>     On Sat, 21 Oct 2023 00:56:21 GMT, Joe Darcy  wrote:
>
>     > Add informative notes to BigInteger and BigDecimal about
>     possible running times, etc.
>
>     The wording looks okay to me and I expect it will appear as an API
>     note in BigInteger.
>
>     However, for BigDecimal I suspect the h2 headings (for the next
>     heading and the existing heading for IEEE 754 Decimal Arithmetic)
>     means they won't look like they are part of the API note, instead
>     they will look like new sections after the API note. Do you see
>     what I mean in the generated javadoc?
>
>     -------------
>
>     Marked as reviewed by alanb (Reviewer).
>
>     PR Review:
>     https://git.openjdk.org/jdk/pull/16298#pullrequestreview-1691219200
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bpb at openjdk.org  Mon Oct 23 21:07:36 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 23 Oct 2023 21:07:36 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 20:47:42 GMT, Joe Darcy  wrote:

>> Add informative notes to BigInteger and BigDecimal about possible running times, etc.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback, fix typos.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16298#pullrequestreview-1693518718

From bpb at openjdk.org  Mon Oct 23 21:07:38 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 23 Oct 2023 21:07:38 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 23 Oct 2023 20:26:00 GMT, Joe Darcy  wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 302:
>> 
>>> 300:  * scale. For example, an {@linkplain BigDecimal#multiply(BigDecimal)
>>> 301:  * exact multiply} of two {@code BigDecimal} values is subject to the
>>> 302:  * same {@linkplain BigInteger##algorithmicComplexity complexity
>> 
>> Does this link need two `##` or only one?
>
> The "##" is used for HTML id's declared in the javadoc.

Okay, thanks.

>> src/java.base/share/classes/java/math/BigInteger.java line 137:
>> 
>>> 135:  * results indicate a multiply algorithm for numbers using this
>>> 136:  * category of representation must run in at least
>>> 137:  * O(n log n). Common multiply
>> 
>> "Common _multiply_" or "Common _multiplication_"?
>
> Doing some grammar research ...
> 
> In English, using a noun as an adjective is called an "attributive noun," so the "multiplication" in "multiplication algorithm" would play that role.
> 
> Strictly speaking to "adjective-ifly" a verb would be to use a participle, one way to do that anyway -- "multiplying algorithm."
> 
> In any case, "multiply algorithm" reads okay to me, but I don't mind changing it to "multiplication algorithm."

Then it's fine as it is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1369262376
PR Review Comment: https://git.openjdk.org/jdk/pull/16298#discussion_r1369263256

From jlu at openjdk.org  Mon Oct 23 21:23:02 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Oct 2023 21:23:02 GMT
Subject: RFR: 8318613: ChoiceFormat patterns are not well tested
Message-ID: 

Please review this PR which adds a test for ChoiceFormat intended to test a wide range of ChoiceFormat patterns.

The existing test _Bug4387255_ only tests a singular basic pattern and does not test for incorrect patterns either.

The new test checks 

- both correct and incorrect patterns
- the behavior of incorrect patterns that either throw an IllegalArgumentException or discard the incorrect portion
- the case of formatting with an empty pattern (that leads to empty limits and formats)

-------------

Commit messages:
 - add test for AIOOBE
 - cleanup
 - init

Changes: https://git.openjdk.org/jdk/pull/16324/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16324&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318613
  Stats: 142 lines in 1 file changed: 142 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16324/head:pull/16324

PR: https://git.openjdk.org/jdk/pull/16324

From darcy at openjdk.org  Mon Oct 23 22:07:49 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Oct 2023 22:07:49 GMT
Subject: RFR: JDK-8318476: Add resource consumption note to BigInteger and
 BigDecimal [v5]
In-Reply-To: 
References: 
Message-ID: <7r5cSgNXU7E6UnBgB2ury4SiPPFBEO3b4VDtbLGxDkQ=.4428b956-7671-4029-a72b-29436af32d1a@github.com>

> Add informative notes to BigInteger and BigDecimal about possible running times, etc.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Re-flow paragraph.
 - Fix a typo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16298/files
  - new: https://git.openjdk.org/jdk/pull/16298/files/0a48c48f..8968c924

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16298&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16298&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16298/head:pull/16298

PR: https://git.openjdk.org/jdk/pull/16298

From darcy at openjdk.org  Mon Oct 23 22:11:41 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Oct 2023 22:11:41 GMT
Subject: Integrated: JDK-8318476: Add resource consumption note to BigInteger
 and BigDecimal
In-Reply-To: 
References: 
Message-ID: <9zFMXtFGpVhfi8X6lLbLGnEz8UDsXQ-T4LOU0GxZMSA=.69f8e899-f8ea-4f55-83d9-05c570efd524@github.com>

On Sat, 21 Oct 2023 00:56:21 GMT, Joe Darcy  wrote:

> Add informative notes to BigInteger and BigDecimal about possible running times, etc.

This pull request has now been integrated.

Changeset: 1b150117
Author:    Joe Darcy 
URL:       https://git.openjdk.org/jdk/commit/1b150117fd9ccb7ff8adc012b74d7d95e5219b94
Stats:     59 lines in 2 files changed: 57 ins; 0 del; 2 mod

8318476: Add resource consumption note to BigInteger and BigDecimal

Reviewed-by: alanb, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/16298

From uschindler at openjdk.org  Mon Oct 23 22:18:37 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Mon, 23 Oct 2023 22:18:37 GMT
Subject: RFR: 8318646: Integer#parseInt("") throws empty
 NumberFormatException message [v2]
In-Reply-To: <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
References: 
 <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
Message-ID: 

On Mon, 23 Oct 2023 18:26:51 GMT, Raffaello Giulietti  wrote:

>> Please review this simple fix to restore the original exception message that existed before [16050](https://github.com/openjdk/jdk/pull/16050).
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove 2 extraneous files from commit

Marked as reviewed by uschindler (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16320#pullrequestreview-1693600033

From naoto at openjdk.org  Mon Oct 23 22:27:31 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Oct 2023 22:27:31 GMT
Subject: RFR: 8318613: ChoiceFormat patterns are not well tested
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 21:15:44 GMT, Justin Lu  wrote:

> Please review this PR which adds a test for ChoiceFormat intended to test a wide range of ChoiceFormat patterns.
> 
> The existing test _Bug4387255_ only tests a singular basic pattern and does not test for incorrect patterns either.
> 
> The new test checks 
> 
> - both correct and incorrect patterns
> - the behavior of incorrect patterns that either throw an IllegalArgumentException or discard the incorrect portion
> - the case of formatting with an empty pattern (that leads to empty limits and formats)

test/jdk/java/text/Format/ChoiceFormat/PatternsTest.java line 48:

> 46: public class PatternsTest {
> 47: 
> 48:     private static final String err1 =

Nit: static constants should be uppercased.

test/jdk/java/text/Format/ChoiceFormat/PatternsTest.java line 59:

> 57:         assertDoesNotThrow( ()-> new ChoiceFormat(pattern),
> 58:                 "Valid pattern should not have thrown an exception");
> 59:     }

For those valid cases, it may be helpful to actually format some edge cases, and check the results, especially for those odd ones. Or compare the parsed arrays.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16324#discussion_r1369320017
PR Review Comment: https://git.openjdk.org/jdk/pull/16324#discussion_r1369319425

From jlu at openjdk.org  Mon Oct 23 23:16:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Oct 2023 23:16:42 GMT
Subject: RFR: 8318613: ChoiceFormat patterns are not well tested [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which adds a test for ChoiceFormat intended to test a wide range of ChoiceFormat patterns.
> 
> The existing test _Bug4387255_ only tests a singular basic pattern and does not test for incorrect patterns either.
> 
> The new test checks 
> 
> - both correct and incorrect patterns
> - the behavior of incorrect patterns that either throw an IllegalArgumentException or discard the incorrect portion
> - the case of formatting with an empty pattern (that leads to empty limits and formats)

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  implement feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16324/files
  - new: https://git.openjdk.org/jdk/pull/16324/files/036cbfa1..2fb5a1a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16324&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16324&range=00-01

  Stats: 34 lines in 1 file changed: 11 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/16324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16324/head:pull/16324

PR: https://git.openjdk.org/jdk/pull/16324

From jlu at openjdk.org  Mon Oct 23 23:16:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Oct 2023 23:16:44 GMT
Subject: RFR: 8318613: ChoiceFormat patterns are not well tested [v2]
In-Reply-To: 
References: 
 
Message-ID: <2Fasxub90ExWLCw1UaxDwtIRe4O7Tjhgwfx4uvz-7XQ=.d553d027-30a2-43fb-912c-2e69a2be3931@github.com>

On Mon, 23 Oct 2023 22:19:15 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   implement feedback
>
> test/jdk/java/text/Format/ChoiceFormat/PatternsTest.java line 59:
> 
>> 57:         assertDoesNotThrow( ()-> new ChoiceFormat(pattern),
>> 58:                 "Valid pattern should not have thrown an exception");
>> 59:     }
> 
> For those valid cases, it may be helpful to actually format some edge cases, and check the results, especially for those odd ones. Or compare the parsed arrays.

Good point, added some code to actually compare the formatted values to the expected results as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16324#discussion_r1369362862

From naoto at openjdk.org  Mon Oct 23 23:29:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Oct 2023 23:29:34 GMT
Subject: RFR: 8318613: ChoiceFormat patterns are not well tested [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 23 Oct 2023 23:16:42 GMT, Justin Lu  wrote:

>> Please review this PR which adds a test for ChoiceFormat intended to test a wide range of ChoiceFormat patterns.
>> 
>> The existing test _Bug4387255_ only tests a singular basic pattern and does not test for incorrect patterns either.
>> 
>> The new test checks 
>> 
>> - both correct and incorrect patterns
>> - the behavior of incorrect patterns that either throw an IllegalArgumentException or discard the incorrect portion
>> - the case of formatting with an empty pattern (that leads to empty limits and formats)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implement feedback

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16324#pullrequestreview-1693680505

From Nico.Williams at twosigma.com  Mon Oct 23 18:50:11 2023
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 23 Oct 2023 18:50:11 +0000
Subject: HttpURLConnection cache issues leading to crashes in JGSS w/
 native GSS introduced by 8303809
In-Reply-To: 
References: <20231019220916.GG202255@twosigma.com>
 
Message-ID: <20231023185011.GA2670319@twosigma.com>

On Mon, Oct 23, 2023 at 04:26:42PM +0100, Michael McMahon wrote:
> Thanks for bringing this to our attention. You are right that this is a
> misuse of the authentication cache in the case of Kerberos (Negotiate)
> authentication. Though that is not the case for other auth schemes, because
> normally what gets cached are credentials, rather than security tokens.

I see.  I guess you could cache `GSSCredential` handles if the caller
were using non-default GSS credentials.  With password-based HTTP
schemes the credentials aren't process-global like GSS credentials
typically are, but rather can vary per request.

> It makes no sense to cache GSS contexts either, outside the scope of any
> individual request (being authenticated through multiple request/responses).
> We don't need to cache it in this situation as it is already kept as a local
> variable in the HttpURLConnection impl class.
> 
> So, my first impression is that the fix here needs to disable the cache
> permanently for the Negotiate scheme, which is basically what the system
> property workaround is doing. But, we need to just be sure about that before
> we publish a PR.

For what it's worth, disabling the cache for Negotiate does indeed work
right now as a workaround.  You can reproduce both, the crashes and the
workaround using the instructions I provided.

Nico
-- 

From darcy at openjdk.org  Tue Oct 24 04:34:29 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 24 Oct 2023 04:34:29 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method [v2]
In-Reply-To: <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>
References: 
 <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>
Message-ID: <-mPIn7ApH5XYSRKZmnjXS8GO0MAkBpgPsBxpwpKDvQk=.a5e70ba4-22d9-4000-87f2-16ad9d9d2237@github.com>

On Fri, 6 Oct 2023 18:07:37 GMT, Justin Lu  wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 
>> 
>> That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tag setChoices as well

I assume this issue was filed (directly or indirectly) in response to the javac lint warning added in JDK 21 under JDK-8015831.

I recommend considering how to address the underlying issue of the constructors calling overridable methods. For example, can a private method be defined that is called from the constructor and the public method?

In any case, I think one goal of bug should be to remove the warning condition, preferably by removing the condition, but, if not, by adding a `@SuppressedException((this-escape")`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16064#issuecomment-1776523348

From lkorinth at openjdk.org  Tue Oct 24 07:49:30 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 07:49:30 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 
Message-ID: 

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * 
 Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      *  and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:

 - static import
 - copyright
 - whitespace
 - whitespace
 - sed
 - fix test/lib/jdk/test/lib/process/ProcessTools.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/f80dda8d..2f57a32d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=04-05

  Stats: 1580 lines in 560 files changed: 44 ins; 34 del; 1502 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

PR: https://git.openjdk.org/jdk/pull/15452

From lkorinth at openjdk.org  Tue Oct 24 09:10:43 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 09:10:43 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth  wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * 
 Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      *  and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Hi, if you want to see what I have modified manually, you can do my sed commands and compare to this pull request:

git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9

find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedTestJavaProcessBuilder/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createTestJvm/import static jdk.test.lib.process.ProcessTools.createTestJavaProcessBuilder/g"
git add -u; git commit -m sed

git diff-tree --no-commit-id --name-only -r 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9..HEAD | xargs sed -i -e "s%^( * Copyright (c) ....)[^[:alpha:]]*(Oracle.*)%\1, 2023, \2%"
git ls-files -m | xargs sed -i -e "s%(Copyright (c) 2023), 2023, (Oracle.*)%\1, \2%"
git add -u; git commit -m copyright

git diff HEAD 2f57a32df8d17da51a04177563327ca2a75e8061


It will give you an easier way to review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1776817287

From alanb at openjdk.org  Tue Oct 24 09:33:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Oct 2023 09:33:30 GMT
Subject: RFR: 8293713 : java/net/httpclient/BufferingSubscriberTest.java
 fails in timeout, blocked in submission publisher
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 15:28:31 GMT, Viktor Klang  wrote:

> Resolves a visibility issue in SubmissionPublisher by making the `waiter` member of BufferedSubscription *volatile*.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16313#pullrequestreview-1694403984

From stefank at openjdk.org  Tue Oct 24 09:51:39 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 24 Oct 2023 09:51:39 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth  wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * 
 Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      *  and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1694437335

From rgiulietti at openjdk.org  Tue Oct 24 10:23:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 24 Oct 2023 10:23:49 GMT
Subject: RFR: 8318646: Integer#parseInt("") throws empty
 NumberFormatException message [v2]
In-Reply-To: 
References: 
 <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
 
Message-ID: 

On Mon, 23 Oct 2023 22:15:48 GMT, Uwe Schindler  wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove 2 extraneous files from commit
>
> Marked as reviewed by uschindler (Author).

@uschindler You may want to make the Lucene tests more robust by making them immune to exception messages contents.

But thanks for trying out the EA releases on important libraries like Lucene ;-) It is important to have early feedback to gain more information before shipping the GA release.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16320#issuecomment-1776928918

From rgiulietti at openjdk.org  Tue Oct 24 10:23:51 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 24 Oct 2023 10:23:51 GMT
Subject: Integrated: 8318646: Integer#parseInt("") throws empty
 NumberFormatException message
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 18:04:35 GMT, Raffaello Giulietti  wrote:

> Please review this simple fix to restore the original exception message that existed before [16050](https://github.com/openjdk/jdk/pull/16050).

This pull request has now been integrated.

Changeset: 9bfa0829
Author:    Raffaello Giulietti 
URL:       https://git.openjdk.org/jdk/commit/9bfa0829700412291ed26e7bb006b8cb63208870
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8318646: Integer#parseInt("") throws empty NumberFormatException message

Reviewed-by: redestad, alanb, bpb, darcy, uschindler

-------------

PR: https://git.openjdk.org/jdk/pull/16320

From vklang at openjdk.org  Tue Oct 24 10:41:40 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 24 Oct 2023 10:41:40 GMT
Subject: Integrated: 8293713 : java/net/httpclient/BufferingSubscriberTest.java
 fails in timeout, blocked in submission publisher
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 15:28:31 GMT, Viktor Klang  wrote:

> Resolves a visibility issue in SubmissionPublisher by making the `waiter` member of BufferedSubscription *volatile*.

This pull request has now been integrated.

Changeset: 5224e979
Author:    Viktor Klang 
Committer: Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/5224e979a1cbce1b015e81aa7761743f60357d73
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8293713: java/net/httpclient/BufferingSubscriberTest.java fails in timeout, blocked in submission publisher

Co-authored-by: Jaikiran Pai 
Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/16313

From uschindler at openjdk.org  Tue Oct 24 10:46:39 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Tue, 24 Oct 2023 10:46:39 GMT
Subject: RFR: 8318646: Integer#parseInt("") throws empty
 NumberFormatException message [v2]
In-Reply-To: 
References: 
 <1Z9AWEKbL8X2j1S9PU756OKcLnAbn6Sdc2FqjNb-NYY=.75ca65d0-cd70-4e3e-8dc6-bed101d2b63f@github.com>
 
Message-ID: 

On Mon, 23 Oct 2023 22:15:48 GMT, Uwe Schindler  wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove 2 extraneous files from commit
>
> Marked as reviewed by uschindler (Author).

> @uschindler You may want to make the Lucene tests more robust by making them immune to exception messages contents.
> 
> But thanks for trying out the EA releases on important libraries like Lucene ;-) It is important to have early feedback to gain more information before shipping the GA release.

Thanks for this. Actually this was a bad example. This was just test code, so I will more or less only remove the message check. In that case it would be enough to check for the NumberFormatException. I will provide a fix for this.

This is a very old test from a not so well-maintained module. Anyways it helped a bit to make the code more clean, because the NumberFormatException is now generated in the same way everywhere which makes it more consistent.

I mainly openend the iusse to inform you about that incompatibility because the exception message looks the same since very early java versions. So suddenly chaging it might bring others into the same situation like we were. I agree the spec does not enforce a message, but a more helpful message is always better than the completely empty one. So I would say, this PR is just a cleanup so "enhancement" as said by Alan Bateman is a good categorization.

Thanks for the quick fix. But I will fix the issue in Lucene, too!

P.S.: At other code we do not rely on exception messages. In recent code of MemorySegment we have some ambiguity with IllegalStateException when the scope of a memory segment was closed. I refused to look into the exception message and instead of parsing mesage, when catching exception, I checked if the memorysegment's scope was closed and only then convert the exception to a Lucene "AlreadyClosedException". In all other cases it was rethrowing the original exception. With exception messages you would have to look for some text string in them which is fragile. See this example: https://github.com/apache/lucene/pull/12707

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16320#issuecomment-1776967713

From jvernee at openjdk.org  Tue Oct 24 12:36:45 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 24 Oct 2023 12:36:45 GMT
Subject: Integrated: 8316046: x64 platforms unecessarily save xmm16-31 when
 UseAVX >= 3
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 11:37:08 GMT, Jorn Vernee  wrote:

> See JBS issue. We don't need to save xmm16+ on x64 platforms (which are currently saved in FFM upcall stubs). This is achieved simply by adding these registers to the volatile register lists of both ABIs.
> 
> Related: https://github.com/openjdk/jdk/pull/15688
> 
> Testing: `jdk_foreign`

This pull request has now been integrated.

Changeset: d1077d6f
Author:    Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/d1077d6f141d6e51f697271286833e01013080d6
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8316046: x64 platforms unecessarily save xmm16-31 when UseAVX >= 3

Reviewed-by: mcimadamore, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/16307

From rriggs at openjdk.org  Tue Oct 24 13:55:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 13:55:35 GMT
Subject: RFR: 8318051: Duration.between uses exceptions for control flow
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 17:33:48 GMT, Eamonn McManus  wrote:

> The existing logic uses nanosecond arithmetic to compute Duration.between. Since that can overflow for durations greater than 292 years, it has a try/catch that falls back to computing the seconds part and adjusting that for nanoseconds. However, exception handling is typically very expensive, so in cases like the one in the linked bug this method was a performance trap.
> 
> The new logic is essentially the old catch block. It needs a special case for when the number of seconds is 0, so it is slightly slower in that case. But in other cases it is probably somewhat faster, because it avoids a [division](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/src/java.base/share/classes/java/time/Duration.java#L283) and associated mod.
> 
> The test coverage in [`TCKDuration`](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/test/jdk/java/time/tck/java/time/TCKDuration.java#L780) is already very thorough so no new tests are needed.

Did you identify an existing test that reproduces your initial issue case?
`Duration.between(instant, Instant.MAX).compareTo(duration) < 0`

Otherwise, looks good

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16318#issuecomment-1777253304

From rriggs at openjdk.org  Tue Oct 24 14:11:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 14:11:30 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method [v2]
In-Reply-To: <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>
References: 
 <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>
Message-ID: 

On Fri, 6 Oct 2023 18:07:37 GMT, Justin Lu  wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 
>> 
>> That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tag setChoices as well

Drive-by comment: typo  "the the" in ChoiceFormat.toPattern(): line 322

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16064#issuecomment-1777295653

From jvernee at openjdk.org  Tue Oct 24 14:49:49 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 24 Oct 2023 14:49:49 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
Message-ID: 

Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.

-------------

Commit messages:
 - Merge branch 'master' into UpcallStubAllocFailure
 - remove unused import
 - add timeout
 - reduce code cache size in test
 - fix copyright header formatting
 - Explicitly handle upcall stub allocation failure

Changes: https://git.openjdk.org/jdk/pull/16311/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318586
  Stats: 87 lines in 4 files changed: 80 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16311/head:pull/16311

PR: https://git.openjdk.org/jdk/pull/16311

From jvernee at openjdk.org  Tue Oct 24 15:09:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 24 Oct 2023 15:09:57 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: 
References: 
Message-ID: 

> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
> 
> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
> 
> Components of this patch:
> 
> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
> - The object/oop + offset is exposed as temporary address to native code.
> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
> - Only x64 and AArch64 for now.
> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
> 
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
> 
> Numbers for the included benchmark on my machine are:
> 
> 
> Benchmark                     (size)  Mode  Cnt       ...

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - a -> an
 - add note to downcallHandle about passing heap segments by-reference

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16201/files
  - new: https://git.openjdk.org/jdk/pull/16201/files/2e00beff..bf850299

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=10-11

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201

PR: https://git.openjdk.org/jdk/pull/16201

From duke at openjdk.org  Tue Oct 24 15:21:39 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 24 Oct 2023 15:21:39 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> By extracting the code that creates the exception, the CodeSize of these methods is less than the default FreqInlineSize 325.  and for the scenario where the most commonly used radix is not specified and the String coder is LATIN1, fast-path can improves the performance 10% of parseInt(String)/parseLong(String).

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - merge from master
 - Merge remote-tracking branch 'upstream/master' into parse_int_long
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/Integer.java
   #	src/java.base/share/classes/java/lang/Long.java
 - fix from @schlosna 's review
 - Optimization for Integer.parseX & Long.parseX

-------------

Changes: https://git.openjdk.org/jdk/pull/16112/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16112&range=01
  Stats: 224 lines in 6 files changed: 170 ins; 24 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/16112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16112/head:pull/16112

PR: https://git.openjdk.org/jdk/pull/16112

From duke at openjdk.org  Tue Oct 24 15:34:07 2023
From: duke at openjdk.org (iaroslavski)
Date: Tue, 24 Oct 2023 15:34:07 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v9]
In-Reply-To: 
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
 <8wFp2rFtTWDGTQ4AKB4QYNjb0eJrg6aDznXP3p8agKE=.a0b699ac-f725-4bfd-9d07-bc7ace20b0a0@github.com>
 
 <4gJ8559jIkiqFQNZHixQ1omfMjW7kKRtjaYFc92Xb90=.b64864d7-a56e-40bd-9581-d5abf97cb7e5@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 16:33:56 GMT, Paul Sandoz  wrote:

>>> > Alan, you mentioned that DualPivotQuicksort will need detailed review. Can we go ahead and start reviewing? Laurent checked performance, JMH results look fine.
>>> 
>>> As before, I think the main question with this change is whether adding radix sort to the mix is worth the complexity and additional code to maintain. Also as we discussed in the previous PR, the additional memory needed for the radix sort may have an effect on other things that are going on concurrently. I know it has been updated to handle OOME but I think potential reviewers would need to be comfortable with that part.
>> 
>> I too share concerns about the potential increased use of memory for sorting ints/longs/floats/doubles. With modern SIMD hardware and data parallel techniques we can apply quicksort much more efficiently. I think it is important to determine to what extent this reduces the need for radix sort. To determine that we would need to carefully measure against the AVX-512 implementation (with ongoing improvements) with appropriately initialized data to sort, and further measure against an AVX2 version.
>
>> Hi Paul (@PaulSandoz), Alan (@AlanBateman), Any update? Do you agree with Radix sort in parallel case only?
> 
> I think its definitely a better fit, but another aspect of my previous comment was wondering if we need a radix sort if the vectorized quicksort implementation is fast enough. IMO we need to compare performance results with the vectorized quick sort, and be aware of future enhancements to that.

Hi Paul (@PaulSandoz), Alan (@AlanBateman),
Any update? What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1777492279

From mcimadamore at openjdk.org  Tue Oct 24 15:38:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 24 Oct 2023 15:38:43 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: 
References: 
 
Message-ID: <91QJMyPdnoSB8zosYyJrCv2s3-aKOItLRm7Q1pLfmko=.dce34b03-9db6-46f6-afa5-be64d4ccf1ce@github.com>

On Tue, 24 Oct 2023 15:09:57 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - a -> an
>  - add note to downcallHandle about passing heap segments by-reference

New javadoc note looks good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16201#pullrequestreview-1695254853

From naoto at openjdk.org  Tue Oct 24 16:58:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Oct 2023 16:58:45 GMT
Subject: Integrated: 8318569: Add getter methods for Locale and Patterns in
 ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: 

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato  wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 11650375
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/116503754c4c4bdb91685955ef4456bc76f751c4
Stats:     60 lines in 2 files changed: 59 ins; 0 del; 1 mod

8318569: Add getter methods for Locale and Patterns in ListFormat

Reviewed-by: joehw, rriggs, iris, mli

-------------

PR: https://git.openjdk.org/jdk/pull/16293

From lmesnik at openjdk.org  Tue Oct 24 17:04:41 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 24 Oct 2023 17:04:41 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1695447658

From joehw at openjdk.org  Tue Oct 24 17:07:48 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 24 Oct 2023 17:07:48 GMT
Subject: RFR: 8318487: Specification of the ListFormat.equals() method can
 be improved [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 17:05:29 GMT, Naoto Sato  wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8318487-ListFormat-equals
>  - Fixing typo
>  - Removed redundant wording
>  - initial commit
>  - Simplified the method spec
>  - initial commit

Looks fine to me. 

Alternatively (or more explicitly), it could be: Compares the specified object with this {@code ListFormat} for equality. Returns true if the given object is also a {@code ListFormat}  and the two represent the same formats, specifically, if both {@code locale} and {@code patterns}, returned from {@link #getLocale()} and {@link #getPatterns()} respectively, are equal.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695451108

From naoto at openjdk.org  Tue Oct 24 17:07:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Oct 2023 17:07:47 GMT
Subject: RFR: 8318487: Specification of the ListFormat.equals() method can
 be improved [v2]
In-Reply-To: 
References: 
Message-ID: 

> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into JDK-8318487-ListFormat-equals
 - Fixing typo
 - Removed redundant wording
 - initial commit
 - Simplified the method spec
 - initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/16321/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16321&range=01
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16321.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16321/head:pull/16321

PR: https://git.openjdk.org/jdk/pull/16321

From lancea at openjdk.org  Tue Oct 24 17:43:36 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 24 Oct 2023 17:43:36 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v2]
In-Reply-To: 
References: 
 
Message-ID: <3oSFTfxctynQhag-ZHhQuu5HxKCkKo5y7X9xXGp0Nzg=.33c466a5-8110-43fe-a19d-b5d6e26630db@github.com>

On Tue, 19 Sep 2023 21:55:24 GMT, Brian Burkhalter  wrote:

>> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274122: Make value of exceptionExpected more robust to Windows version

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15460#pullrequestreview-1695517205

From naoto at openjdk.org  Tue Oct 24 17:58:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Oct 2023 17:58:49 GMT
Subject: RFR: 8318487: Specification of the ListFormat.equals() method can
 be improved [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 24 Oct 2023 17:04:25 GMT, Joe Wang  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review comments
>
> Looks fine to me. 
> 
> Alternatively (or more explicitly), it could be: Compares the specified object with this {@code ListFormat} for equality. Returns true if the given object is also a {@code ListFormat}  and the two represent the same formats, specifically, if both {@code locale} and {@code patterns}, returned from {@link #getLocale()} and {@link #getPatterns()} respectively, are equal.

Thanks, @JoeWang-Java 
In fact, your suggested style aligns with other `Format` classes, such as `DateFormat`/`NumberFormat`. Modified the wording to align with them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16321#issuecomment-1777742029

From naoto at openjdk.org  Tue Oct 24 17:58:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Oct 2023 17:58:48 GMT
Subject: RFR: 8318487: Specification of the ListFormat.equals() method can
 be improved [v3]
In-Reply-To: 
References: 
Message-ID: 

> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16321/files
  - new: https://git.openjdk.org/jdk/pull/16321/files/0e586395..57b91b4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16321&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16321&range=01-02

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16321.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16321/head:pull/16321

PR: https://git.openjdk.org/jdk/pull/16321

From djelinski at openjdk.org  Tue Oct 24 18:01:41 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 24 Oct 2023 18:01:41 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 21:55:24 GMT, Brian Burkhalter  wrote:

>> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274122: Make value of exceptionExpected more robust to Windows version

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15460#pullrequestreview-1695541801

From rriggs at openjdk.org  Tue Oct 24 18:01:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 18:01:42 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 21:55:24 GMT, Brian Burkhalter  wrote:

>> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274122: Make value of exceptionExpected more robust to Windows version

There are newer jdk.internal.util APIs to check OS and version but they need jtreg to open up java.base.  See OperatingSystem and OSVersion if interested.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15460#pullrequestreview-1695544345

From bpb at openjdk.org  Tue Oct 24 18:01:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 24 Oct 2023 18:01:44 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v2]
In-Reply-To: <3oSFTfxctynQhag-ZHhQuu5HxKCkKo5y7X9xXGp0Nzg=.33c466a5-8110-43fe-a19d-b5d6e26630db@github.com>
References: 
 
 <3oSFTfxctynQhag-ZHhQuu5HxKCkKo5y7X9xXGp0Nzg=.33c466a5-8110-43fe-a19d-b5d6e26630db@github.com>
Message-ID: 

On Tue, 24 Oct 2023 17:40:34 GMT, Lance Andersen  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274122: Make value of exceptionExpected more robust to Windows version
>
> Marked as reviewed by lancea (Reviewer).

Thanks  @LanceAndersen , @djelinski , and @RogerRiggs . I will look at `OSVersion`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15460#issuecomment-1777748107

From duke at openjdk.org  Tue Oct 24 18:05:12 2023
From: duke at openjdk.org (amittoranainc)
Date: Tue, 24 Oct 2023 18:05:12 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v42]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 23:36:48 GMT, Srinivas Vamsi Parasa  wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - fix code style and formatting
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into avx512sort
>  - Update CompileThresholdScaling only for the sort and partition intrinsics; update build script to remove nested if
>  - change variable names of indexPivot* to pivotIndex*
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>  - Remove the unnecessary exception in single pivot partitioning fallback method
>  - Move functional interfaces close to the associated methods
>  - Refactor the sort and partition intrinsics to accept method references for fallback functions
>  - Refactor stub handling to use a generic function for all types
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a1c9587c...a5262d86

can I use this function for sorting excel file data with multiple columns in it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1777727402

From emcmanus at openjdk.org  Tue Oct 24 18:17:35 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Tue, 24 Oct 2023 18:17:35 GMT
Subject: RFR: 8318051: Duration.between uses exceptions for control flow
In-Reply-To: 
References: 
Message-ID: <-6UL2NfKbTp4vfVNBHJRJHiwS89tCAohc3-AXW_s1x4=.ede77ba7-4487-498c-8236-589b49eb4d2a@github.com>

On Mon, 23 Oct 2023 17:33:48 GMT, Eamonn McManus  wrote:

> The existing logic uses nanosecond arithmetic to compute Duration.between. Since that can overflow for durations greater than 292 years, it has a try/catch that falls back to computing the seconds part and adjusting that for nanoseconds. However, exception handling is typically very expensive, so in cases like the one in the linked bug this method was a performance trap.
> 
> The new logic is essentially the old catch block. It needs a special case for when the number of seconds is 0, so it is slightly slower in that case. But in other cases it is probably somewhat faster, because it avoids a [division](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/src/java.base/share/classes/java/time/Duration.java#L283) and associated mod.
> 
> The test coverage in [`TCKDuration`](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/test/jdk/java/time/tck/java/time/TCKDuration.java#L780) is already very thorough so no new tests are needed.

Yes, what I tried was just removing the catch-block from the existing code and verifying that `TCKDuration` fails with `ArithmeticException`. It calls `between` on `Instant` values that are 500 years apart, which is enough to trigger nanosecond overflow. So both the original `try` and the original `catch` are tested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16318#issuecomment-1777777159

From rriggs at openjdk.org  Tue Oct 24 18:23:34 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 18:23:34 GMT
Subject: RFR: 8318051: Duration.between uses exceptions for control flow
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 17:33:48 GMT, Eamonn McManus  wrote:

> The existing logic uses nanosecond arithmetic to compute Duration.between. Since that can overflow for durations greater than 292 years, it has a try/catch that falls back to computing the seconds part and adjusting that for nanoseconds. However, exception handling is typically very expensive, so in cases like the one in the linked bug this method was a performance trap.
> 
> The new logic is essentially the old catch block. It needs a special case for when the number of seconds is 0, so it is slightly slower in that case. But in other cases it is probably somewhat faster, because it avoids a [division](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/src/java.base/share/classes/java/time/Duration.java#L283) and associated mod.
> 
> The test coverage in [`TCKDuration`](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/test/jdk/java/time/tck/java/time/TCKDuration.java#L780) is already very thorough so no new tests are needed.

Thanks for the fix and confirming the test.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16318#pullrequestreview-1695608215

From bpb at openjdk.org  Tue Oct 24 18:30:31 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 24 Oct 2023 18:30:31 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 21:55:24 GMT, Brian Burkhalter  wrote:

>> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274122: Make value of exceptionExpected more robust to Windows version

On Windows 11 hardware `jdk/internal/util/OSTest.java` prints

STARTED    OSTest::checkOsVersion 'checkOsVersion()'
os.version: 10.0, version().toString(): 10.0
SUCCESSFUL OSTest::checkOsVersion 'checkOsVersion()'

as the kernel version is still 10.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15460#issuecomment-1777797940

From emcmanus at openjdk.org  Tue Oct 24 18:35:41 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Tue, 24 Oct 2023 18:35:41 GMT
Subject: Integrated: 8318051: Duration.between uses exceptions for control flow
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 17:33:48 GMT, Eamonn McManus  wrote:

> The existing logic uses nanosecond arithmetic to compute Duration.between. Since that can overflow for durations greater than 292 years, it has a try/catch that falls back to computing the seconds part and adjusting that for nanoseconds. However, exception handling is typically very expensive, so in cases like the one in the linked bug this method was a performance trap.
> 
> The new logic is essentially the old catch block. It needs a special case for when the number of seconds is 0, so it is slightly slower in that case. But in other cases it is probably somewhat faster, because it avoids a [division](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/src/java.base/share/classes/java/time/Duration.java#L283) and associated mod.
> 
> The test coverage in [`TCKDuration`](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/test/jdk/java/time/tck/java/time/TCKDuration.java#L780) is already very thorough so no new tests are needed.

This pull request has now been integrated.

Changeset: 9c819fd3
Author:    Eamonn McManus 
URL:       https://git.openjdk.org/jdk/commit/9c819fd3b7e564b53514185573f4ffe28368b46b
Stats:     32 lines in 1 file changed: 17 ins; 14 del; 1 mod

8318051: Duration.between uses exceptions for control flow

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/16318

From joehw at openjdk.org  Tue Oct 24 18:43:30 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 24 Oct 2023 18:43:30 GMT
Subject: RFR: 8318487: Specification of the ListFormat.equals() method can
 be improved [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 17:58:48 GMT, Naoto Sato  wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

Thanks for the update, looks good again :-). Nice to know the javadoc styles are aligned.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695642472

From rriggs at openjdk.org  Tue Oct 24 18:48:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 18:48:35 GMT
Subject: RFR: 8318487: Specification of the ListFormat.equals() method can
 be improved [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 17:58:48 GMT, Naoto Sato  wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695650865

From lancea at openjdk.org  Tue Oct 24 18:53:36 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 24 Oct 2023 18:53:36 GMT
Subject: RFR: 8318487: Specification of the ListFormat.equals() method can
 be improved [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 17:58:48 GMT, Naoto Sato  wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695659263

From iris at openjdk.org  Tue Oct 24 18:58:29 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 24 Oct 2023 18:58:29 GMT
Subject: RFR: 8318487: Specification of the ListFormat.equals() method can
 be improved [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 17:58:48 GMT, Naoto Sato  wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

Corresponding CSR also Reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695669443

From rriggs at openjdk.org  Tue Oct 24 19:42:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 19:42:43 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 
 
Message-ID: <6qyfRp98A2DA7Q7YhscmdmokkIvVVn9HxB_XjRdM47g=.615d7a65-e109-41db-b955-31c0a934debd@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

test/lib/jdk/test/lib/process/ProcessTools.java line 506:

> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List command) {
> 506:         return createTestJavaProcessBuilder(command.toArray(String[]::new));

The javadoc shoul d describe all of the options being added to the ProcessBuilder.
They were inadequated described previously and still are.
The other options (seem to be from the code), test.noclasspath, java.class.path, and test.thread.factory.
The description of test.thread.factory and addTestThreadFactoryArgs method seems inadequately described.

test/lib/jdk/test/lib/process/ProcessTools.java line 527:

> 525:      * Create ProcessBuilder using the java launcher from the jdk to
> 526:      * be tested.
> 527:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for `reateTestJavaProcessBuilder(...)`

test/lib/jdk/test/lib/process/ProcessTools.java line 549:

> 547:      * Create ProcessBuilder using the java launcher from the jdk to
> 548:      * be tested.
> 549:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for reateTestJavaProcessBuilder(...)

test/lib/jdk/test/lib/process/ProcessTools.java line 599:

> 597:      */
> 598:     public static OutputAnalyzer executeTestJvm(String... cmds) throws Exception {
> 599:         ProcessBuilder pb = createTestJavaProcessBuilder(cmds);

This should also describe *all* of the options being set in the ProcessBuilder before executing the process.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370728371
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729609
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729925
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370730637

From darcy at openjdk.org  Tue Oct 24 20:14:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 24 Oct 2023 20:14:36 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v53]
In-Reply-To: 
References: 
 
Message-ID: <7DJ6wF4vfhZsYgaZMdWIl2BrD62b4WQqWKnrN9tKcmc=.af289f2b-777f-4b13-9aad-47ced379a7dd@github.com>

On Fri, 20 Oct 2023 21:26:51 GMT, Doug Lea 
 wrote:

>> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
>> 
>> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.
>
> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 101 commits:
> 
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Merge master
>  - Ensure liveness for InterruptibleTasks
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - More cleanup
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - better window encoding
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - cleanup
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - ... and 91 more: https://git.openjdk.org/jdk/compare/a1a62d99...84f06bcf

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3285:

> 3283: 
> 3284:     /**
> 3285:      * Uninterrupible version of {@code InvokeAll}. Executes the given

Typo: "InvokeAll" vs "invokeAll".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1370761609

From almatvee at openjdk.org  Tue Oct 24 21:44:43 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 24 Oct 2023 21:44:43 GMT
Subject: Integrated: 8311877: [macos] Add CLI options to provide signing
 identity directly to codesign and productbuild
In-Reply-To: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 22:15:00 GMT, Alexander Matveev  wrote:

> - Added `--mac-app-image-sign-identity` and `--mac-installer-sign-identity` CLI options to jpackage to provide signing identity directly to `codesign` and `productbuild` tools as per CSR [JDK-8316631](https://bugs.openjdk.org/browse/JDK-8316631).
> - If `codesign` or `productbuild` fails, then output of these tools will be printed to stdout to help user diagnose issues with signing using new options. Examples with sign identity set to "test" which does not exist on system:
>> Error: "codesign" failed with following output:
>> test: no identity found
> 
>> Error: "productbuild" failed with following output:
>> productbuild: error: Cannot write product to "/Users/SOMEDIR/Test-1.0.pkg". (Could not find appropriate signing identity for ?test?.)
> - Added error handling not to allow invalid combinations of signing options.
> - Updated signing tests to test new changes.

This pull request has now been integrated.

Changeset: f1dfdc1a
Author:    Alexander Matveev 
URL:       https://git.openjdk.org/jdk/commit/f1dfdc1a79f3a16eae58d15d1945541a08f7e145
Stats:     555 lines in 24 files changed: 450 ins; 24 del; 81 mod

8311877: [macos] Add CLI options to provide signing identity directly to codesign and productbuild

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/16085

From bpb at openjdk.org  Tue Oct 24 22:57:59 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 24 Oct 2023 22:57:59 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8274122: Use internal OperatingSystem and OSVersion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15460/files
  - new: https://git.openjdk.org/jdk/pull/15460/files/1d18442c..7d3b2432

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15460&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15460&range=01-02

  Stats: 9 lines in 1 file changed: 5 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15460/head:pull/15460

PR: https://git.openjdk.org/jdk/pull/15460

From bpb at openjdk.org  Tue Oct 24 23:02:29 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 24 Oct 2023 23:02:29 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 22:57:59 GMT, Brian Burkhalter  wrote:

>> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274122: Use internal OperatingSystem and OSVersion

To allow creation of files with reserved names, it appears that the OS must be Windows 11, or some future variant with a kernel version > 10. Windows 10 and 11, and Server 2019 and 2022 all appear to have kernel version 10, but from what I've seen only Windows 11 allows creation of these files. This test will probably break again in the future, but commit 7d3b243 passed 102 repeats.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15460#issuecomment-1778186915

From rriggs at openjdk.org  Wed Oct 25 02:20:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 25 Oct 2023 02:20:40 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 22:57:59 GMT, Brian Burkhalter  wrote:

>> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274122: Use internal OperatingSystem and OSVersion

Thanks for trying out the OSVersion API.  (Though it doesn't seem to cover all the cases).

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15460#pullrequestreview-1696218488

From jbhateja at openjdk.org  Wed Oct 25 05:25:11 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 25 Oct 2023 05:25:11 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets.
Message-ID: 

Hi All,

This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.

Following is the summary of changes:-

1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact
JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro.


![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)


2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.

3) Some minor adjustments in existing gather instruction pattens for double/quad words.


Kindly review and share your feedback.


Best Regards,
Jatin

-------------

Commit messages:
 - 8318650: Optimized subword gather for x86 targets.

Changes: https://git.openjdk.org/jdk/pull/16354/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318650
  Stats: 1186 lines in 31 files changed: 1123 ins; 34 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/16354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16354/head:pull/16354

PR: https://git.openjdk.org/jdk/pull/16354

From jbhateja at openjdk.org  Wed Oct 25 05:25:11 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 25 Oct 2023 05:25:11 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets.
In-Reply-To: 
References: 
Message-ID: 

On Wed, 25 Oct 2023 04:34:59 GMT, Jatin Bhateja  wrote:

> Hi All,
> 
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
> 
> Following is the summary of changes:-
> 
> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact
> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro.
> 
> 
> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
> 
> 
> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
> 
> 3) Some minor adjustments in existing gather instruction pattens for double/quad words.
> 
> 
> Kindly review and share your feedback.
> 
> 
> Best Regards,
> Jatin

**Detailed performance numberers with AVX2**

Benchmark | Size | Baseline Score (ops/ms) | WithOpt Score (ops/ms) | Gain Factor (opt/baseline)
-- | -- | -- | -- | --
GatherOperationsBenchmark.microByteGather128 | 64 | 15916.774 | 34288.944 | 2.154264677
GatherOperationsBenchmark.microByteGather128 | 256 | 4128.501 | 8793.293 | 2.12989969
GatherOperationsBenchmark.microByteGather128 | 1024 | 1027.606 | 2217.138 | 2.157575958
GatherOperationsBenchmark.microByteGather128 | 4096 | 264.002 | 554.603 | 2.100753025
GatherOperationsBenchmark.microByteGather128_MASK | 64 | 16729.183 | 26308.667 | 1.57262115
GatherOperationsBenchmark.microByteGather128_MASK | 256 | 4157.73 | 7312.934 | 1.758876599
GatherOperationsBenchmark.microByteGather128_MASK | 1024 | 1067.675 | 1828.035 | 1.712164282
GatherOperationsBenchmark.microByteGather128_MASK | 4096 | 268.538 | 462.191 | 1.721138163
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF | 64 | 16559.725 | 25355.415 | 1.531149521
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF | 256 | 4190.36 | 6596.82 | 1.574284787
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF | 1024 | 1070.641 | 1638.323 | 1.530226285
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF | 4096 | 274.703 | 415.345 | 1.511978391
GatherOperationsBenchmark.microByteGather128_NZ_OFF | 64 | 15445.814 | 30518.41 | 1.975836948
GatherOperationsBenchmark.microByteGather128_NZ_OFF | 256 | 4087.154 | 8075.382 | 1.975795872
GatherOperationsBenchmark.microByteGather128_NZ_OFF | 1024 | 1035.527 | 2008.003 | 1.939112162
GatherOperationsBenchmark.microByteGather128_NZ_OFF | 4096 | 262.936 | 501.675 | 1.907973804
GatherOperationsBenchmark.microByteGather256 | 64 | 18266.25 | 37549.708 | 2.05568784
GatherOperationsBenchmark.microByteGather256 | 256 | 4714.027 | 9894.099 | 2.098863456
GatherOperationsBenchmark.microByteGather256 | 1024 | 1147.282 | 2490.351 | 2.1706529
GatherOperationsBenchmark.microByteGather256 | 4096 | 286.935 | 622.153 | 2.16827156
GatherOperationsBenchmark.microByteGather256_MASK | 64 | 21992.019 | 27357.032 | 1.243952727
GatherOperationsBenchmark.microByteGather256_MASK | 256 | 5732.258 | 7760.398 | 1.353811709
GatherOperationsBenchmark.microByteGather256_MASK | 1024 | 1495.632 | 1964.343 | 1.313386582
GatherOperationsBenchmark.microByteGather256_MASK | 4096 | 386.313 | 480.509 | 1.243833368
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF | 64 | 19911.793 | 26818.552 | 1.346867758
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF | 256 | 5013.248 | 7040.98 | 1.404474704
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF | 1024 | 1289.123 | 1785.368 | 1.384947751
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF | 4096 | 332.791 | 452.568 | 1.359916584
GatherOperationsBenchmark.microByteGather256_NZ_OFF | 64 | 17147.769 | 33913.351 | 1.977712144
GatherOperationsBenchmark.microByteGather256_NZ_OFF | 256 | 4386.044 | 8640.734 | 1.970051828
GatherOperationsBenchmark.microByteGather256_NZ_OFF | 1024 | 1097.485 | 2261.998 | 2.061074183
GatherOperationsBenchmark.microByteGather256_NZ_OFF | 4096 | 277.155 | 565.051 | 2.038754488
GatherOperationsBenchmark.microByteGather64 | 64 | 13068.085 | 37960.616 | 2.904833876
GatherOperationsBenchmark.microByteGather64 | 256 | 3227.857 | 9935.642 | 3.078092369
GatherOperationsBenchmark.microByteGather64 | 1024 | 834.99 | 2530.696 | 3.03080995
GatherOperationsBenchmark.microByteGather64 | 4096 | 212.664 | 637.938 | 2.999746078
GatherOperationsBenchmark.microByteGather64_MASK | 64 | 13548.225 | 30755.634 | 2.27008586
GatherOperationsBenchmark.microByteGather64_MASK | 256 | 3347.844 | 8026.22 | 2.39742951
GatherOperationsBenchmark.microByteGather64_MASK | 1024 | 843.279 | 2072.913 | 2.458157976
GatherOperationsBenchmark.microByteGather64_MASK | 4096 | 213.316 | 544.853 | 2.554205967
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF | 64 | 12982.383 | 28193.925 | 2.171706458
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF | 256 | 3288.497 | 7483.684 | 2.275715623
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF | 1024 | 834.342 | 1860.542 | 2.229951267
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF | 4096 | 208.107 | 473.987 | 2.277611998
GatherOperationsBenchmark.microByteGather64_NZ_OFF | 64 | 13079.567 | 32992.977 | 2.522482357
GatherOperationsBenchmark.microByteGather64_NZ_OFF | 256 | 3321.098 | 8987.837 | 2.706284789
GatherOperationsBenchmark.microByteGather64_NZ_OFF | 1024 | 865.324 | 2362.563 | 2.73026404
GatherOperationsBenchmark.microByteGather64_NZ_OFF | 4096 | 216.768 | 575.35 | 2.65422018
GatherOperationsBenchmark.microShortGather128 | 64 | 12835.472 | 31370.111 | 2.44401694
GatherOperationsBenchmark.microShortGather128 | 256 | 3151.091 | 8603.442 | 2.730305789
GatherOperationsBenchmark.microShortGather128 | 1024 | 820.026 | 2158.645 | 2.632410436
GatherOperationsBenchmark.microShortGather128 | 4096 | 205.263 | 535.444 | 2.60857534
GatherOperationsBenchmark.microShortGather128_MASK | 64 | 13055.905 | 23957.317 | 1.834979421
GatherOperationsBenchmark.microShortGather128_MASK | 256 | 3234.501 | 6416.879 | 1.983885304
GatherOperationsBenchmark.microShortGather128_MASK | 1024 | 829.648 | 1578.415 | 1.902511668
GatherOperationsBenchmark.microShortGather128_MASK | 4096 | 206.04 | 416.303 | 2.02049602
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF | 64 | 12905.373 | 22475.815 | 1.74158585
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF | 256 | 3202.372 | 5695.988 | 1.778677805
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF | 1024 | 814.645 | 1412.466 | 1.733842349
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF | 4096 | 199.535 | 355.407 | 1.781176235
GatherOperationsBenchmark.microShortGather128_NZ_OFF | 64 | 12329.793 | 27620.341 | 2.240130147
GatherOperationsBenchmark.microShortGather128_NZ_OFF | 256 | 3146.016 | 7664.47 | 2.436246351
GatherOperationsBenchmark.microShortGather128_NZ_OFF | 1024 | 794.335 | 1925.535 | 2.424084297
GatherOperationsBenchmark.microShortGather128_NZ_OFF | 4096 | 195.754 | 485.942 | 2.482411598
GatherOperationsBenchmark.microShortGather256 | 64 | 15430.153 | 33050.636 | 2.141951282
GatherOperationsBenchmark.microShortGather256 | 256 | 4042.835 | 8901.664 | 2.201837077
GatherOperationsBenchmark.microShortGather256 | 1024 | 986.361 | 2180.195 | 2.210341853
GatherOperationsBenchmark.microShortGather256 | 4096 | 250.057 | 560.523 | 2.24158092
GatherOperationsBenchmark.microShortGather256_MASK | 64 | 16793.012 | 23516.915 | 1.400398868
GatherOperationsBenchmark.microShortGather256_MASK | 256 | 4249.641 | 6505.857 | 1.5309192
GatherOperationsBenchmark.microShortGather256_MASK | 1024 | 1105.868 | 1600.44 | 1.447225166
GatherOperationsBenchmark.microShortGather256_MASK | 4096 | 268.443 | 410.052 | 1.527519809
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF | 64 | 16107.265 | 22559.877 | 1.400602585
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF | 256 | 4035.417 | 5872.376 | 1.455209214
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF | 1024 | 1028.671 | 1469.825 | 1.428858206
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF | 4096 | 258.639 | 370.997 | 1.434420176
GatherOperationsBenchmark.microShortGather256_NZ_OFF | 64 | 14761.16 | 27601.245 | 1.869856095
GatherOperationsBenchmark.microShortGather256_NZ_OFF | 256 | 3905.104 | 7684.751 | 1.967873583
GatherOperationsBenchmark.microShortGather256_NZ_OFF | 1024 | 986.575 | 1853.319 | 1.878538378
GatherOperationsBenchmark.microShortGather256_NZ_OFF | 4096 | 248.541 | 485.734 | 1.954341537
GatherOperationsBenchmark.microShortGather64 | 64 | 7942.618 | 33097.908 | 4.167128269
GatherOperationsBenchmark.microShortGather64 | 256 | 2009.148 | 9039.775 | 4.499307667
GatherOperationsBenchmark.microShortGather64 | 1024 | 506.769 | 2198.022 | 4.33732529
GatherOperationsBenchmark.microShortGather64 | 4096 | 118.499 | 565.551 | 4.772622554
GatherOperationsBenchmark.microShortGather64_MASK | 64 | 7802.345 | 23559.186 | 3.019500676
GatherOperationsBenchmark.microShortGather64_MASK | 256 | 1917.049 | 6278.454 | 3.275061827
GatherOperationsBenchmark.microShortGather64_MASK | 1024 | 491.248 | 1569.524 | 3.194972804
GatherOperationsBenchmark.microShortGather64_MASK | 4096 | 117.255 | 398.438 | 3.398046992
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF | 64 | 7697.165 | 22599.8 | 2.936119987
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF | 256 | 1913.269 | 5986.04 | 3.128697533
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF | 1024 | 483.724 | 1491.969 | 3.084339417
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF | 4096 | 116.716 | 375.492 | 3.217142465
GatherOperationsBenchmark.microShortGather64_NZ_OFF | 64 | 7882.26 | 29755.573 | 3.775005265
GatherOperationsBenchmark.microShortGather64_NZ_OFF | 256 | 1992.655 | 7969.383 | 3.99937922
GatherOperationsBenchmark.microShortGather64_NZ_OFF | 1024 | 498.249 | 1997.082 | 4.008200719
GatherOperationsBenchmark.microShortGather64_NZ_OFF | 4096 | 117.764 | 497.177 | 4.221808023







**Detailed performance numbers with AVX3**


Benchmark | Size | Baseline Score (ops/ms) | WithOpt Score (ops/ms) | Gain Factor (opt/baseline)
-- | -- | -- | -- | --
GatherOperationsBenchmark.microByteGather128 | 64 | 15900.681 | 35745.941 | 2.248076104
GatherOperationsBenchmark.microByteGather128 | 256 | 4194.349 | 9931.187 | 2.36775409
GatherOperationsBenchmark.microByteGather128 | 1024 | 1064.611 | 2528.468 | 2.375015851
GatherOperationsBenchmark.microByteGather128 | 4096 | 270.486 | 633.351 | 2.341529691
GatherOperationsBenchmark.microByteGather128_MASK | 64 | 17836.944 | 30418.654 | 1.705373634
GatherOperationsBenchmark.microByteGather128_MASK | 256 | 4411.449 | 8451.317 | 1.915768946
GatherOperationsBenchmark.microByteGather128_MASK | 1024 | 1155.587 | 2119.895 | 1.8344746
GatherOperationsBenchmark.microByteGather128_MASK | 4096 | 287.88 | 538.807 | 1.871637488
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF | 64 | 16678.512 | 27223.074 | 1.632224385
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF | 256 | 4268.674 | 7395.33 | 1.732465398
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF | 1024 | 1119.764 | 1854.529 | 1.656178445
GatherOperationsBenchmark.microByteGather128_MASK_NZ_OFF | 4096 | 276.836 | 469.102 | 1.694512274
GatherOperationsBenchmark.microByteGather128_NZ_OFF | 64 | 15561.662 | 33674.023 | 2.163909163
GatherOperationsBenchmark.microByteGather128_NZ_OFF | 256 | 4065.922 | 9427.52 | 2.318667205
GatherOperationsBenchmark.microByteGather128_NZ_OFF | 1024 | 1030.027 | 2430.395 | 2.359544944
GatherOperationsBenchmark.microByteGather128_NZ_OFF | 4096 | 261.51 | 609.811 | 2.331884058
GatherOperationsBenchmark.microByteGather256 | 64 | 17993.999 | 36026.071 | 2.002115872
GatherOperationsBenchmark.microByteGather256 | 256 | 4646.105 | 9695.417 | 2.086783876
GatherOperationsBenchmark.microByteGather256 | 1024 | 1131.979 | 2487.113 | 2.197137049
GatherOperationsBenchmark.microByteGather256 | 4096 | 278.159 | 624.745 | 2.24599959
GatherOperationsBenchmark.microByteGather256_MASK | 64 | 22898.291 | 30126.448 | 1.315663601
GatherOperationsBenchmark.microByteGather256_MASK | 256 | 5473.285 | 8843.556 | 1.615767496
GatherOperationsBenchmark.microByteGather256_MASK | 1024 | 1415.369 | 2230.048 | 1.575594774
GatherOperationsBenchmark.microByteGather256_MASK | 4096 | 358.725 | 556.882 | 1.552392501
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF | 64 | 20186.469 | 27915.464 | 1.382879988
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF | 256 | 5214.919 | 7578.939 | 1.453318642
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF | 1024 | 1360.825 | 1902.398 | 1.397974023
GatherOperationsBenchmark.microByteGather256_MASK_NZ_OFF | 4096 | 359.569 | 487.59 | 1.356040148
GatherOperationsBenchmark.microByteGather256_NZ_OFF | 64 | 17154.31 | 35904.295 | 2.093018897
GatherOperationsBenchmark.microByteGather256_NZ_OFF | 256 | 4404.264 | 8997.564 | 2.042921133
GatherOperationsBenchmark.microByteGather256_NZ_OFF | 1024 | 1098.961 | 2317.713 | 2.109003868
GatherOperationsBenchmark.microByteGather256_NZ_OFF | 4096 | 275.722 | 576.866 | 2.092201565
GatherOperationsBenchmark.microByteGather512 | 64 | 18790.829 | 38455.649 | 2.046511572
GatherOperationsBenchmark.microByteGather512 | 256 | 4806.001 | 10023.706 | 2.085664568
GatherOperationsBenchmark.microByteGather512 | 1024 | 1164.771 | 2558.357 | 2.19644634
GatherOperationsBenchmark.microByteGather512 | 4096 | 286.714 | 640.06 | 2.232398836
GatherOperationsBenchmark.microByteGather512_MASK | 64 | 25265.683 | 32738.543 | 1.295771145
GatherOperationsBenchmark.microByteGather512_MASK | 256 | 6417.048 | 8900.835 | 1.387060686
GatherOperationsBenchmark.microByteGather512_MASK | 1024 | 1726.425 | 2231.39 | 1.29249171
GatherOperationsBenchmark.microByteGather512_MASK | 4096 | 438.445 | 562.29 | 1.282464163
GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF | 64 | 22097.788 | 29326.431 | 1.32712066
GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF | 256 | 5587.934 | 7937.573 | 1.420484387
GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF | 1024 | 1485.739 | 1967.966 | 1.324570466
GatherOperationsBenchmark.microByteGather512_MASK_NZ_OFF | 4096 | 350.395 | 502.295 | 1.433510752
GatherOperationsBenchmark.microByteGather512_NZ_OFF | 64 | 17904.091 | 34883.849 | 1.948373084
GatherOperationsBenchmark.microByteGather512_NZ_OFF | 256 | 4532.971 | 9354.373 | 2.063629571
GatherOperationsBenchmark.microByteGather512_NZ_OFF | 1024 | 1135.769 | 2394.267 | 2.108058065
GatherOperationsBenchmark.microByteGather512_NZ_OFF | 4096 | 285.823 | 588.764 | 2.059890212
GatherOperationsBenchmark.microByteGather64 | 64 | 13044.341 | 32947.355 | 2.525796819
GatherOperationsBenchmark.microByteGather64 | 256 | 3244.318 | 8817.036 | 2.717685504
GatherOperationsBenchmark.microByteGather64 | 1024 | 812.016 | 2205.047 | 2.715521615
GatherOperationsBenchmark.microByteGather64 | 4096 | 212.882 | 559.439 | 2.627930027
GatherOperationsBenchmark.microByteGather64_MASK | 64 | 13328.592 | 25055.284 | 1.879814762
GatherOperationsBenchmark.microByteGather64_MASK | 256 | 3294.445 | 6779.14 | 2.057748726
GatherOperationsBenchmark.microByteGather64_MASK | 1024 | 832.091 | 1693.255 | 2.034939688
GatherOperationsBenchmark.microByteGather64_MASK | 4096 | 213.049 | 432.162 | 2.028462936
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF | 64 | 12713.428 | 23246.19 | 1.828475373
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF | 256 | 3238.82 | 6168.581 | 1.904576667
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF | 1024 | 819.699 | 1548.811 | 1.889487483
GatherOperationsBenchmark.microByteGather64_MASK_NZ_OFF | 4096 | 207.266 | 388.488 | 1.874345045
GatherOperationsBenchmark.microByteGather64_NZ_OFF | 64 | 12740.659 | 28229.421 | 2.215695515
GatherOperationsBenchmark.microByteGather64_NZ_OFF | 256 | 3255.884 | 7816.444 | 2.400713293
GatherOperationsBenchmark.microByteGather64_NZ_OFF | 1024 | 831.691 | 1976.915 | 2.376982557
GatherOperationsBenchmark.microByteGather64_NZ_OFF | 4096 | 210.812 | 503.111 | 2.386538717
GatherOperationsBenchmark.microShortGather128 | 64 | 12858.925 | 34710.696 | 2.699346641
GatherOperationsBenchmark.microShortGather128 | 256 | 3106.472 | 9171.459 | 2.952371372
GatherOperationsBenchmark.microShortGather128 | 1024 | 819.192 | 2278.838 | 2.781811834
GatherOperationsBenchmark.microShortGather128 | 4096 | 204.157 | 575.636 | 2.819575131
GatherOperationsBenchmark.microShortGather128_MASK | 64 | 12528.506 | 28202.741 | 2.251085724
GatherOperationsBenchmark.microShortGather128_MASK | 256 | 3236.653 | 7798 | 2.409278968
GatherOperationsBenchmark.microShortGather128_MASK | 1024 | 820.409 | 1991.597 | 2.427566007
GatherOperationsBenchmark.microShortGather128_MASK | 4096 | 203.635 | 509.145 | 2.500282368
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF | 64 | 12166.914 | 25418.26 | 2.089129585
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF | 256 | 3202.89 | 6914.467 | 2.158821252
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF | 1024 | 799.485 | 1752.541 | 2.192087406
GatherOperationsBenchmark.microShortGather128_MASK_NZ_OFF | 4096 | 199.868 | 442.822 | 2.215572278
GatherOperationsBenchmark.microShortGather128_NZ_OFF | 64 | 12531.197 | 31505.217 | 2.514142663
GatherOperationsBenchmark.microShortGather128_NZ_OFF | 256 | 3150.884 | 9098.353 | 2.887555683
GatherOperationsBenchmark.microShortGather128_NZ_OFF | 1024 | 806.932 | 2280.42 | 2.826037386
GatherOperationsBenchmark.microShortGather128_NZ_OFF | 4096 | 197.351 | 571.426 | 2.895480641
GatherOperationsBenchmark.microShortGather256 | 64 | 15255.994 | 34013.422 | 2.22951202
GatherOperationsBenchmark.microShortGather256 | 256 | 3986.306 | 9196.43 | 2.307005533
GatherOperationsBenchmark.microShortGather256 | 1024 | 1003.058 | 2294.437 | 2.287442002
GatherOperationsBenchmark.microShortGather256 | 4096 | 257.45 | 560.259 | 2.176185667
GatherOperationsBenchmark.microShortGather256_MASK | 64 | 17194.868 | 26817.506 | 1.559622673
GatherOperationsBenchmark.microShortGather256_MASK | 256 | 4307.911 | 7252.799 | 1.683600009
GatherOperationsBenchmark.microShortGather256_MASK | 1024 | 1109.034 | 1803.594 | 1.626274758
GatherOperationsBenchmark.microShortGather256_MASK | 4096 | 274.104 | 458.023 | 1.670982547
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF | 64 | 15615.164 | 25553.091 | 1.636427962
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF | 256 | 4041.88 | 6826.642 | 1.688976912
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF | 1024 | 1037.741 | 1706.208 | 1.644155912
GatherOperationsBenchmark.microShortGather256_MASK_NZ_OFF | 4096 | 257.732 | 439.843 | 1.706590567
GatherOperationsBenchmark.microShortGather256_NZ_OFF | 64 | 14795.183 | 31449.844 | 2.125681311
GatherOperationsBenchmark.microShortGather256_NZ_OFF | 256 | 3931.158 | 8463.181 | 2.15284682
GatherOperationsBenchmark.microShortGather256_NZ_OFF | 1024 | 989.033 | 2120.528 | 2.144041705
GatherOperationsBenchmark.microShortGather256_NZ_OFF | 4096 | 247.472 | 537.454 | 2.171777009
GatherOperationsBenchmark.microShortGather512 | 64 | 17122.803 | 33007.209 | 1.927675568
GatherOperationsBenchmark.microShortGather512 | 256 | 4378.354 | 9043.805 | 2.065571902
GatherOperationsBenchmark.microShortGather512 | 1024 | 1058.899 | 2292.852 | 2.165316994
GatherOperationsBenchmark.microShortGather512 | 4096 | 255.502 | 577.995 | 2.262193642
GatherOperationsBenchmark.microShortGather512_MASK | 64 | 21232.499 | 27840.109 | 1.311202652
GatherOperationsBenchmark.microShortGather512_MASK | 256 | 5520.535 | 8068.078 | 1.461466688
GatherOperationsBenchmark.microShortGather512_MASK | 1024 | 1424.798 | 2058.709 | 1.444912893
GatherOperationsBenchmark.microShortGather512_MASK | 4096 | 355.353 | 472.564 | 1.329843845
GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF | 64 | 19155.458 | 25609.616 | 1.336935718
GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF | 256 | 4927.708 | 7004.695 | 1.421491493
GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF | 1024 | 1275.924 | 1773.667 | 1.390103956
GatherOperationsBenchmark.microShortGather512_MASK_NZ_OFF | 4096 | 312.012 | 444.827 | 1.425672731
GatherOperationsBenchmark.microShortGather512_NZ_OFF | 64 | 16195.665 | 33555.966 | 2.071910354
GatherOperationsBenchmark.microShortGather512_NZ_OFF | 256 | 4123.235 | 7852.8 | 1.904523996
GatherOperationsBenchmark.microShortGather512_NZ_OFF | 1024 | 1033.009 | 1722.473 | 1.667432714
GatherOperationsBenchmark.microShortGather512_NZ_OFF | 4096 | 256.001 | 441.754 | 1.725594822
GatherOperationsBenchmark.microShortGather64 | 64 | 7717.303 | 34015.02 | 4.40763049
GatherOperationsBenchmark.microShortGather64 | 256 | 1940.575 | 9191.168 | 4.73631166
GatherOperationsBenchmark.microShortGather64 | 1024 | 490.29 | 2294.718 | 4.680327969
GatherOperationsBenchmark.microShortGather64 | 4096 | 117.59 | 579.407 | 4.927349264
GatherOperationsBenchmark.microShortGather64_MASK | 64 | 7325.501 | 26815.558 | 3.660576662
GatherOperationsBenchmark.microShortGather64_MASK | 256 | 1792.717 | 7265.925 | 4.053023985
GatherOperationsBenchmark.microShortGather64_MASK | 1024 | 456.88 | 1805.418 | 3.951624059
GatherOperationsBenchmark.microShortGather64_MASK | 4096 | 109.657 | 454.874 | 4.148152877
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF | 64 | 7157.769 | 25542.547 | 3.568506751
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF | 256 | 1763.398 | 6817.439 | 3.866080715
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF | 1024 | 453.254 | 1704.752 | 3.761140553
GatherOperationsBenchmark.microShortGather64_MASK_NZ_OFF | 4096 | 108.622 | 439.762 | 4.0485537
GatherOperationsBenchmark.microShortGather64_NZ_OFF | 64 | 7708.116 | 31334.47 | 4.065126939
GatherOperationsBenchmark.microShortGather64_NZ_OFF | 256 | 1954.153 | 8460.249 | 4.329368785
GatherOperationsBenchmark.microShortGather64_NZ_OFF | 1024 | 493.538 | 2120.589 | 4.296708663
GatherOperationsBenchmark.microShortGather64_NZ_OFF | 4096 | 116.976 | 537.472 | 4.594720285

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1778499766
PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1778500434

From lucy at openjdk.org  Wed Oct 25 06:34:55 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 25 Oct 2023 06:34:55 GMT
Subject: RFR: 8318705: [macos] ProblemList
 java/rmi/registry/multipleRegistries/MultipleRegistries.java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 24 Oct 2023 09:51:20 GMT, Goetz Lindenmaier  wrote:

> ?tipleRegistries.java
> 
> The test fails in our CI with the message listed here. We see both, aarch and x86_64. It happens rarely, but a long time back.

LGTM.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16341#pullrequestreview-1694866872

From goetz at openjdk.org  Wed Oct 25 06:34:55 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 25 Oct 2023 06:34:55 GMT
Subject: RFR: 8318705: [macos] ProblemList
 java/rmi/registry/multipleRegistries/MultipleRegistries.java
Message-ID: 

?tipleRegistries.java

The test fails in our CI with the message listed here. We see both, aarch and x86_64. It happens rarely, but a long time back.

-------------

Commit messages:
 - 8318705: [macos] ProblemList java/rmi/registry/multipleRegistries/MultipleRegistries.java

Changes: https://git.openjdk.org/jdk/pull/16341/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16341&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318705
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16341.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16341/head:pull/16341

PR: https://git.openjdk.org/jdk/pull/16341

From djelinski at openjdk.org  Wed Oct 25 06:44:38 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Oct 2023 06:44:38 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 22:57:59 GMT, Brian Burkhalter  wrote:

>> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274122: Use internal OperatingSystem and OSVersion

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15460#pullrequestreview-1696485885

From david.holmes at oracle.com  Wed Oct 25 07:12:47 2023
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Oct 2023 17:12:47 +1000
Subject: RFC: 8318776: Require supports_cx8 to always be true
Message-ID: <517d7c08-e9a6-481a-89e5-2533c5d41724@oracle.com>

 From  https://bugs.openjdk.org/browse/JDK-8318776

Regardless of platform size (32-bit or 64-bit) the Java language has 
always required that the underlying platform (or the VM) provides a 
means of performing atomic load and store of 64-bit values, for volatile 
long and double support.

Since Java 5 the java.util.concurrent.atomic package introduced APIs 
that provide a range of atomic operations, the most fundamental being a 
compare-and-swap (CAS), also known as a compare-exchange, out of which 
other atomic operations can be constructed if there is no direct 
platform support. This capability was later extended to the VarHandle 
API as well.

While all platforms needed a mechanism for 64-bit load and store, not 
all platforms support a 64-bit CAS, internally known as cmpxchg8. To 
address that the supports_cx8 flag was introduced so that on platforms 
without cmpxchg8 native support, it could be emulated via other 
techniques e.g. locking. (Note this is not without its own issues as all 
accesses to the field must be done in a way that is consistent with the 
use of locking by cmpxchg8 - word-tearing is a real risk).

Internal to the VM we also have use of lock-free algorithms and atomic 
operations, with the latter defined via atomic.hpp. Originally in that 
code we needed to check supports_cx8 for platforms without 64-bit 
support, but in practice we tended to avoid using 64-bit fields in such 
cases so we could avoid the complexity of introducing lock-based emulation.

Unfortunately, when the atomic interface in the VM was templatized and 
redesigned, it appears that the fact cmpxchg8 may not be available was 
overlooked and supports_cx8 is not consulted. Consequently if someone 
introduced an atomic operation on a 64-bit field they would get a 
linkage error on platforms without cmpxchg8 - so again if this happened 
we tended to back away from using a 64-bit field.

Along the way the access API in the VM was introduced, which also 
provided atomic ops on oops and did consult supports_cx8 with a 
lock-based fallback.

We have now reached a point where there are cases where we do want 
64-bit atomic operations but we don't want the complexity of dealing 
with platforms that don't support it. So we want to require that 
supports_cx8 always be assumed true (the VM could abort at runtime if 
run on a platform where it is not true) and we can then proceed with 
64-bit atomics in the VM and also remove all the lock-based fallbacks in 
the access API and in the Java APIs.

The OpenJDK has limited support for 32-bit platforms these days: PPC32 
was dropped a long time ago; Windows 32-bit is now a deprecated port 
(but supports cmpxchg8 anyway); leaving only ARM32 as a platform of 
potential concern. But even then we support cmpxchg8 in all known modern 
implementations, as described in os_cpu/linux_arm/atomic_linux_arm.hpp:

/*
  * Atomic long operations on 32-bit ARM
  * ARM v7 supports LDREXD/STREXD synchronization instructions so no 
problem.
  * ARM < v7 does not have explicit 64 atomic load/store capability.
  * However, gcc emits LDRD/STRD instructions on v5te and LDM/STM on v5t
  * when loading/storing 64 bits.
  * For non-MP machines (which is all we support for ARM < v7)
  * under current Linux distros these instructions appear atomic.
  * See section A3.5.3 of ARM Architecture Reference Manual for ARM v7.
  * Also, for cmpxchg64, if ARM < v7 we check for cmpxchg64 support in the
  * Linux kernel using _kuser_helper_version. See entry-armv.S in the Linux
  * kernel source or kernel_user_helpers.txt in Linux Doc.
  */

So the practical reality is that we do not expect to encounter any 
mainstream OpenJDK platform where we don't in fact have support for 
cmpxchg8.

-------

Before I proceed with this does anyone have any strong and reasonable 
objections? Is there some platform support aspect that has been overlooked?

Note the JDK part could be (probably should be) done as a follow up RFE 
to simplify the review and approval process.

Thanks,
David

From stefank at openjdk.org  Wed Oct 25 07:27:32 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Oct 2023 07:27:32 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: 
References: 
 
 <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>
 
Message-ID: 

On Tue, 5 Sep 2023 18:05:34 GMT, Roger Riggs  wrote:

>> I have created an alternative that uses enums to force the user to make a decision: https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools . Another alternative is to do the same but instead using an enum (I think it is not as good). A third alternative is to use the current pull request with a better name.
>> 
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test cases.
>
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test ca
> 
> The current API (name) is fine and fit for purpose; it does not promise or hide extra functionality under a simple name.
> 
> There needs to be an explicit intention in the test(s) to support after the fact that arbitrary flags can be added.
> @AlanBateman's proposal for naming [above](https://github.com/openjdk/jdk/pull/15452#issuecomment-1700459277) (or similar) would capture more clearly that test options are propagated to the child process.
> Every test writer should be aware that additional command line options may be mixed in.
> 
> There are many cases in which the ProcessTools APIs are not used to create child processes and do not need to be used in writing tests. They provide some convenience but also add a dependency and another API layer to work through in the case of failures.
> 
> As far as I'm aware, there is no general guidance or design pattern outside of hotspot tests to propagate flags or use ProcessTools. Adding that as a requirement will need a different level of communication and change.

@RogerRiggs You seem to know what you want w.r.t. the extra java doc comments. Could you help write those? Could we also do that as a separate RFE? I think that would make it easier to get this PR and the javadoc update through the door.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1778669353

From lkorinth at openjdk.org  Wed Oct 25 08:44:29 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 25 Oct 2023 08:44:29 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 
Message-ID: 

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  fix copyright year and indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/2f57a32d..4cc3865a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=05-06

  Stats: 23 lines in 1 file changed: 0 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

PR: https://git.openjdk.org/jdk/pull/15452

From jvernee at openjdk.org  Wed Oct 25 08:54:44 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 08:54:44 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle
Message-ID: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>

The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.

While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:


FATAL ERROR in native method: Bad global or local ref passed to JNI
        at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
        at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
        at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
        at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
        at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
        at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
        at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
        at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
        at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
        at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
        at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
        at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
        at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
        at java.lang.reflect.Method.invoke(java.base at 22-internal/Method.java:580)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.lang.Thread.runWith(java.base at 22-internal/Thread.java:1583)
        at java.lang.Thread.run(java.base at 22-internal/Thread.java:1570)


(while with the current code, we crash and generate an hs_err file)

Testing: tier 1-5, local run of `jdk_foreign` with fallback linker and `-Xcheck:jni`

[1]: https://github.com/openjdk/jdk/blob/6f352740cb5e7c47d226fd4039cfb977c0622488/src/hotspot/share/prims/jvm.cpp#L3548
[2]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#getobjectreftype

-------------

Commit messages:
 - bail out when FindClass returns NULL
 - add -Xcheck:jni to tests
 - use global ref for LibFallback_class

Changes: https://git.openjdk.org/jdk/pull/16349/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16349&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318737
  Stats: 15 lines in 6 files changed: 4 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16349.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16349/head:pull/16349

PR: https://git.openjdk.org/jdk/pull/16349

From alanb at openjdk.org  Wed Oct 25 08:54:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Oct 2023 08:54:46 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle
In-Reply-To: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
Message-ID: 

On Tue, 24 Oct 2023 17:01:35 GMT, Jorn Vernee  wrote:

> The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.
> 
> While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:
> 
> 
> FATAL ERROR in native method: Bad global or local ref passed to JNI
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
>         at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
>         at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
>         at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
>         at java.lang.reflect.Method.invoke(java.base at 22-internal/Method.java:580...

src/java.base/share/native/libfallbackLinker/fallbackLinker.c line 48:

> 46: Java_jdk_internal_foreign_abi_fallback_LibFallback_init(JNIEnv* env, jclass cls) {
> 47:   (*env)->GetJavaVM(env, &VM);
> 48:   LibFallback_class = (*env)->NewGlobalRef(env, (*env)->FindClass(env, "jdk/internal/foreign/abi/fallback/LibFallback"));

It might be better to bail if FindClass returns null as there will be pending exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1370739992

From jvernee at openjdk.org  Wed Oct 25 08:54:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 08:54:46 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle
In-Reply-To: 
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 
Message-ID: 

On Tue, 24 Oct 2023 19:49:17 GMT, Alan Bateman  wrote:

>> The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.
>> 
>> While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:
>> 
>> 
>> FATAL ERROR in native method: Bad global or local ref passed to JNI
>>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
>>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
>>         at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
>>         at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
>>         at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
>>         at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
>>         at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
>>         at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
>>         at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
>>         at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
>>         at java.lang.reflect.Method.invo...
>
> src/java.base/share/native/libfallbackLinker/fallbackLinker.c line 48:
> 
>> 46: Java_jdk_internal_foreign_abi_fallback_LibFallback_init(JNIEnv* env, jclass cls) {
>> 47:   (*env)->GetJavaVM(env, &VM);
>> 48:   LibFallback_class = (*env)->NewGlobalRef(env, (*env)->FindClass(env, "jdk/internal/foreign/abi/fallback/LibFallback"));
> 
> It might be better to bail if FindClass returns null as there will be pending exception.

Good point. Will do

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1370785574

From jpai at openjdk.org  Wed Oct 25 09:07:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Oct 2023 09:07:30 GMT
Subject: RFR: JDK-8315921: Invalid CSS declarations in java.lang class
 documentation
In-Reply-To: 
References: 
Message-ID: <7QjkX0HCOF65hls1-LgZqqr9MblbizFVp7ZFwkQ85XM=.dd128603-e487-4f04-a01d-8219bc720f7f@github.com>

On Fri, 15 Sep 2023 13:56:21 GMT, Hannes Walln?fer  wrote:

> This change fixes two errors in inline HTML styles in the `java.lang` package: 
> 
>  - wrong CSS property name in `java.lang.String` 
>  - CSS declaration terminated by colon instead of semicolon in `java.lang.Thread`
> 
> Both errors caused the style declarations to be ignored and an error message to be shown in the browser console. 
> 
> The bug is `noreg-doc`, I tested the docs in the browser to make sure the error message is gone and the HTML displays as intended.

Hello Hannes, the changes look fine to me. I wasn't aware we had custom CSS usage within javadoc tags in the JDK.

src/java.base/share/classes/java/lang/Thread.java line 192:

> 190:  * with the following system properties:
> 191:  * 
> 192:  * 

Just out of curiosity, is that semi-colon even needed, or would `display:none` be enough?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15762#pullrequestreview-1696767564
PR Review Comment: https://git.openjdk.org/jdk/pull/15762#discussion_r1371410008

From jpai at openjdk.org  Wed Oct 25 09:11:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Oct 2023 09:11:36 GMT
Subject: RFR: JDK-8315921: Invalid CSS declarations in java.lang class
 documentation
In-Reply-To: <7QjkX0HCOF65hls1-LgZqqr9MblbizFVp7ZFwkQ85XM=.dd128603-e487-4f04-a01d-8219bc720f7f@github.com>
References: 
 <7QjkX0HCOF65hls1-LgZqqr9MblbizFVp7ZFwkQ85XM=.dd128603-e487-4f04-a01d-8219bc720f7f@github.com>
Message-ID: 

On Wed, 25 Oct 2023 09:05:11 GMT, Jaikiran Pai  wrote:

>> This change fixes two errors in inline HTML styles in the `java.lang` package: 
>> 
>>  - wrong CSS property name in `java.lang.String` 
>>  - CSS declaration terminated by colon instead of semicolon in `java.lang.Thread`
>> 
>> Both errors caused the style declarations to be ignored and an error message to be shown in the browser console. 
>> 
>> The bug is `noreg-doc`, I tested the docs in the browser to make sure the error message is gone and the HTML displays as intended.
>
> src/java.base/share/classes/java/lang/Thread.java line 192:
> 
>> 190:  * with the following system properties:
>> 191:  * 
System properties

>> 192:  * 
> 
> Just out of curiosity, is that semi-colon even needed, or would `display:none` be enough?

Now that I think about it, do you know why the `display:none` is being set here? I have very limited knowledge of CSS, wouldn't the use of `display:none` make the `System Properties` caption text invisible?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15762#discussion_r1371414879

From jpai at openjdk.org  Wed Oct 25 09:14:29 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Oct 2023 09:14:29 GMT
Subject: RFR: 8318705: [macos] ProblemList
 java/rmi/registry/multipleRegistries/MultipleRegistries.java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 24 Oct 2023 09:51:20 GMT, Goetz Lindenmaier  wrote:

> ?tipleRegistries.java
> 
> The test fails in our CI with the message listed here. We see both, aarch and x86_64. It happens rarely, but a long time back.

Looks OK to me, but I think the serviceability area reviewers might want to review this. I'll go ahead and add `serviceability` label to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16341#issuecomment-1778841190

From shade at openjdk.org  Wed Oct 25 09:19:39 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Oct 2023 09:19:39 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
In-Reply-To: 
References: 
Message-ID: <1rw3igIH8g-aGQQxiV9-WZMk2HnR4KAyrvAHymFKgJ8=.d853d1f8-9e30-4966-b474-38a2e4f678e9@github.com>

On Mon, 23 Oct 2023 13:58:27 GMT, Jorn Vernee  wrote:

> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.

I find it pretty weird to terminate the VM if we cannot allocate upcall stub. Does this mean the user code could actually terminate the VM on this `fatal`? Unit test suggests so.

Can the VM code actually handle things without upcall stub present, if e.g. memory is exhausted?

src/hotspot/share/code/codeBlob.cpp line 761:

> 759:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
> 760:     blob = new (size) UpcallStub(name, cb, size, receiver, frame_data_offset);
> 761:     if (blob == nullptr) {

I think it would be safer to call into `fatal` without having `CodeCache_lock` held. Move it out of `MutexLocker` scope?

-------------

PR Review: https://git.openjdk.org/jdk/pull/16311#pullrequestreview-1696785943
PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1371421151

From shade at openjdk.org  Wed Oct 25 09:36:37 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Oct 2023 09:36:37 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle
In-Reply-To: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
Message-ID: <3aLLEdrWdzlYJ4P-vzj0rjkZJOjdVwEzpWaZBGnB-Nc=.a7d99af6-3167-469e-a595-9944b5d7d7ad@github.com>

On Tue, 24 Oct 2023 17:01:35 GMT, Jorn Vernee  wrote:

> The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.
> 
> While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:
> 
> 
> FATAL ERROR in native method: Bad global or local ref passed to JNI
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
>         at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
>         at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
>         at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
>         at java.lang.reflect.Method.invoke(java.base at 22-internal/Method.java:580...

A few comments:

src/hotspot/share/runtime/jniHandles.cpp line 202:

> 200:       ShouldNotReachHere();
> 201:     }
> 202:   } else if (is_local_handle(thread, handle) || is_frame_handle(thread, handle)) {

Should we still add `ShouldNotReachHere()` at global `else` branch? This would make the if-else chain exhaustive with the early warning if some handle type is not used. The prior code did this already.

src/java.base/share/native/libfallbackLinker/fallbackLinker.c line 52:

> 50:     return; // let caller deal with exception
> 51:   }
> 52:   LibFallback_class = (*env)->NewGlobalRef(env, LibFallback_class_local);

I think `NewGlobalRef` can return `nullptr` on OOME: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#NewGlobalRef

We should check for this too?

-------------

PR Review: https://git.openjdk.org/jdk/pull/16349#pullrequestreview-1696818430
PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1371441723
PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1371445731

From jvernee at openjdk.org  Wed Oct 25 09:39:40 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 09:39:40 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
In-Reply-To: <1rw3igIH8g-aGQQxiV9-WZMk2HnR4KAyrvAHymFKgJ8=.d853d1f8-9e30-4966-b474-38a2e4f678e9@github.com>
References: 
 <1rw3igIH8g-aGQQxiV9-WZMk2HnR4KAyrvAHymFKgJ8=.d853d1f8-9e30-4966-b474-38a2e4f678e9@github.com>
Message-ID: <8yTHPYd8-rR8lbnP74hIzQ6ziHc2Urx3PvuXo5aRrig=.8cb1dcf9-989f-4b33-85ba-efca7e82856e@github.com>

On Wed, 25 Oct 2023 09:13:56 GMT, Aleksey Shipilev  wrote:

>> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.
>
> src/hotspot/share/code/codeBlob.cpp line 761:
> 
>> 759:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
>> 760:     blob = new (size) UpcallStub(name, cb, size, receiver, frame_data_offset);
>> 761:     if (blob == nullptr) {
> 
> I think it would be safer to call into `fatal` without having `CodeCache_lock` held. Move it out of `MutexLocker` scope?

This pattern follows what is done in `RuntimeStub::new_runtime_stub`, which also calls `fatal` under the lock.

I agree it's probably better to call outside of the lock (and that is something I noticed in the original change for RuntimeStub as well). I'm happy to fix it for both.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1371450770

From jvernee at openjdk.org  Wed Oct 25 09:44:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 09:44:30 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
In-Reply-To: <1rw3igIH8g-aGQQxiV9-WZMk2HnR4KAyrvAHymFKgJ8=.d853d1f8-9e30-4966-b474-38a2e4f678e9@github.com>
References: 
 <1rw3igIH8g-aGQQxiV9-WZMk2HnR4KAyrvAHymFKgJ8=.d853d1f8-9e30-4966-b474-38a2e4f678e9@github.com>
Message-ID: 

On Wed, 25 Oct 2023 09:16:25 GMT, Aleksey Shipilev  wrote:

> I find it pretty weird to terminate the VM if we cannot allocate upcall stub. Does this mean the user code could actually terminate the VM on this `fatal`? Unit test suggests so.
> 
> Can the VM code actually handle things without upcall stub present, if e.g. memory is exhausted?

I think the question is whether the user can do anything reasonable if the allocation fails. Upcall stubs are allocated as a result of a call to `Linker.upcallStub`. That means that, one way or another we can not satisfy a direct user request, and the allocation failure would be visible. Whether that is through a fatal error, or some kind of exception, I'm not sure.

But it sounds like you're saying that plain user code should never result in a VM error (if we can help it). That is something I agree with. We'd have to throw some exception from `Linker.upcallStub` if the allocation fails (not sure of OOME is the right one for CodeCache exhaustion). And probably the same for `Linker.downcallLinker`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1778890991

From jvernee at openjdk.org  Wed Oct 25 09:49:39 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 09:49:39 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle
In-Reply-To: <3aLLEdrWdzlYJ4P-vzj0rjkZJOjdVwEzpWaZBGnB-Nc=.a7d99af6-3167-469e-a595-9944b5d7d7ad@github.com>
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 <3aLLEdrWdzlYJ4P-vzj0rjkZJOjdVwEzpWaZBGnB-Nc=.a7d99af6-3167-469e-a595-9944b5d7d7ad@github.com>
Message-ID: 

On Wed, 25 Oct 2023 09:29:43 GMT, Aleksey Shipilev  wrote:

>> The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.
>> 
>> While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:
>> 
>> 
>> FATAL ERROR in native method: Bad global or local ref passed to JNI
>>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
>>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
>>         at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
>>         at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
>>         at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
>>         at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
>>         at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
>>         at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
>>         at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
>>         at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
>>         at java.lang.reflect.Method.invo...
>
> src/hotspot/share/runtime/jniHandles.cpp line 202:
> 
>> 200:       ShouldNotReachHere();
>> 201:     }
>> 202:   } else if (is_local_handle(thread, handle) || is_frame_handle(thread, handle)) {
> 
> Should we still add `ShouldNotReachHere()` at global `else` branch? This would make the if-else chain exhaustive with the early warning if some handle type is not used. The prior code did this already.

Not sure what you're saying here. As far as I understand the intent of this code is to check whether the handle is of a certain type, and if it's not recognized, return `JNIInvalidRefType`. So, I'm not sure there should be any `ShouldNotReachHere()` in this code.

We can add an `else` branch that returns `JNIInvalidRefType` though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1371463282

From shade at openjdk.org  Wed Oct 25 09:52:38 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Oct 2023 09:52:38 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
In-Reply-To: 
References: 
 <1rw3igIH8g-aGQQxiV9-WZMk2HnR4KAyrvAHymFKgJ8=.d853d1f8-9e30-4966-b474-38a2e4f678e9@github.com>
 
Message-ID: 

On Wed, 25 Oct 2023 09:41:33 GMT, Jorn Vernee  wrote:

> But it sounds like you're saying that plain user code should never result in a VM error (if we can help it).

Yes, exactly. Granted, there are resource exhaustion situations where the overall progress could be sluggish (e.g. if we near the Java heap OOME), but we don't usually elevate that to globally shutting down the JVM, unless user explicitly requests this, e.g. with `-XX:+ExitOnOutOfMemoryError`.

I think the situation for `RuntimeStub`-s is a bit different, as we expect to have more or less constant number of them, mostly allocated upfront. Failing to allocate `RuntimeStub` then looks like a configuration issue. But for `UpcallStub`-s -- correct me if I am wrong here -- we can have unbounded number of them, right? Which exposes us to globally visible VM failure if there is a misbehaving code.

It is not the problem with this concrete PR, which I think is fine, but it exposes the larger, more important architectural question.

>> src/hotspot/share/code/codeBlob.cpp line 761:
>> 
>>> 759:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
>>> 760:     blob = new (size) UpcallStub(name, cb, size, receiver, frame_data_offset);
>>> 761:     if (blob == nullptr) {
>> 
>> I think it would be safer to call into `fatal` without having `CodeCache_lock` held. Move it out of `MutexLocker` scope?
>
> This pattern follows what is done in `RuntimeStub::new_runtime_stub`, which also calls `fatal` under the lock.
> 
> I agree it's probably better to call outside of the lock (and that is something I noticed in the original change for RuntimeStub as well). I'm happy to fix it for both.

It is okay to handle `RuntimeStub` in a separate (and more cleanly backportable) PR. Let's make the new code do the right thing from the start.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1778900128
PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1371465261

From jvernee at openjdk.org  Wed Oct 25 09:56:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 09:56:29 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
In-Reply-To: 
References: 
 <1rw3igIH8g-aGQQxiV9-WZMk2HnR4KAyrvAHymFKgJ8=.d853d1f8-9e30-4966-b474-38a2e4f678e9@github.com>
 
 
Message-ID: <5AFSQH0LwfL3BkoKzjWD9D7NeItBUrYCg4qwxO7WHSA=.0019f98b-5950-41fa-b06a-b156dfa77ba3@github.com>

On Wed, 25 Oct 2023 09:47:13 GMT, Aleksey Shipilev  wrote:

> > But it sounds like you're saying that plain user code should never result in a VM error (if we can help it).
> 
> Yes, exactly. Granted, there are resource exhaustion situations where the overall progress could be sluggish (e.g. if we near the Java heap OOME), but we don't usually elevate that to globally shutting down the JVM, unless user explicitly requests this, e.g. with `-XX:+ExitOnOutOfMemoryError`.
> 
> I think the situation for `RuntimeStub`-s is a bit different, as we expect to have more or less constant number of them, mostly allocated upfront. Failing to allocate `RuntimeStub` then looks like a configuration issue. But for `UpcallStub`-s -- correct me if I am wrong here -- we can have unbounded number of them, right? Which exposes us to globally visible VM failure if there is a misbehaving code.

FWIW, we use RuntimeStub for downcall stubs allocated by the linker. So there is also an unbounded number of those. (Well technically bounded by the 255 argument limit * all argument type combinations, but that number is very large).

> It is not the problem with this concrete PR, which I think is fine, but it exposes the larger, more important architectural question.

Ok, I'll discuss with the others in the FFM team. I think if we turn this failure into an OOME (leaning on that side at the moment), then we also need a spec change + CSR.

I'll wait with this PR until we reach some conclusion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1778912083

From shade at openjdk.org  Wed Oct 25 09:59:36 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Oct 2023 09:59:36 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
In-Reply-To: <5AFSQH0LwfL3BkoKzjWD9D7NeItBUrYCg4qwxO7WHSA=.0019f98b-5950-41fa-b06a-b156dfa77ba3@github.com>
References: 
 <1rw3igIH8g-aGQQxiV9-WZMk2HnR4KAyrvAHymFKgJ8=.d853d1f8-9e30-4966-b474-38a2e4f678e9@github.com>
 
 
 <5AFSQH0LwfL3BkoKzjWD9D7NeItBUrYCg4qwxO7WHSA=.0019f98b-5950-41fa-b06a-b156dfa77ba3@github.com>
Message-ID: 

On Wed, 25 Oct 2023 09:54:14 GMT, Jorn Vernee  wrote:

> I'll wait with this PR until we reach some conclusion.

I think we can proceed with this PR. The explicit failure is still better than a failure somewhere downstream. That is, this PR does not change the failure mode substantially, right? If something else is doable, like throwing the actual exception, we can replace this `fatal` with throwing the exception later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1778916151

From jvernee at openjdk.org  Wed Oct 25 10:03:26 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 10:03:26 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
In-Reply-To: 
References: 
 <1rw3igIH8g-aGQQxiV9-WZMk2HnR4KAyrvAHymFKgJ8=.d853d1f8-9e30-4966-b474-38a2e4f678e9@github.com>
 
 
 <5AFSQH0LwfL3BkoKzjWD9D7NeItBUrYCg4qwxO7WHSA=.0019f98b-5950-41fa-b06a-b156dfa77ba3@github.com>
 
Message-ID: 

On Wed, 25 Oct 2023 09:56:45 GMT, Aleksey Shipilev  wrote:

> this PR does not change the failure mode substantially, right?

That's right.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1778922469

From shade at openjdk.org  Wed Oct 25 10:04:37 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Oct 2023 10:04:37 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle
In-Reply-To: 
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 <3aLLEdrWdzlYJ4P-vzj0rjkZJOjdVwEzpWaZBGnB-Nc=.a7d99af6-3167-469e-a595-9944b5d7d7ad@github.com>
 
Message-ID: 

On Wed, 25 Oct 2023 09:46:44 GMT, Jorn Vernee  wrote:

>> src/hotspot/share/runtime/jniHandles.cpp line 202:
>> 
>>> 200:       ShouldNotReachHere();
>>> 201:     }
>>> 202:   } else if (is_local_handle(thread, handle) || is_frame_handle(thread, handle)) {
>> 
>> Should we still add `ShouldNotReachHere()` at global `else` branch? This would make the if-else chain exhaustive with the early warning if some handle type is not used. The prior code did this already.
>
> Not sure what you're saying here. As far as I understand the intent of this code is to check whether the handle is of a certain type, and if it's not recognized, return `JNIInvalidRefType`. So, I'm not sure there should be any `ShouldNotReachHere()` in this code.
> 
> We can add an `else` branch that returns `JNIInvalidRefType` though.

The old code would throw `ShouldNotReachHere()` if we did not recognize the handle type:
https://github.com/openjdk/jdk/blob/d2d1592dd94e897fae6fc4098e43b4fffb6d6750/src/hotspot/share/runtime/jniHandles.cpp#L207

I think the new code should still keep it, like so:


 } else if (is_local_handle(thread, handle) || is_frame_handle(thread, handle)) {
   ...
 } else {
   ShouldNotReachHere();
 }


That way, if we ever have another handle type, we would hit the `else` branch instead of silently returning `JNIInvalidRefType`. That is, our condition chain would still be exhaustive, catching unexpected values explicitly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1371481515

From shade at openjdk.org  Wed Oct 25 10:07:37 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Oct 2023 10:07:37 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 13:58:27 GMT, Jorn Vernee  wrote:

> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16311#pullrequestreview-1696885596

From jvernee at openjdk.org  Wed Oct 25 10:08:38 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 10:08:38 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle
In-Reply-To: 
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 <3aLLEdrWdzlYJ4P-vzj0rjkZJOjdVwEzpWaZBGnB-Nc=.a7d99af6-3167-469e-a595-9944b5d7d7ad@github.com>
 
 
Message-ID: 

On Wed, 25 Oct 2023 10:01:29 GMT, Aleksey Shipilev  wrote:

>> Not sure what you're saying here. As far as I understand the intent of this code is to check whether the handle is of a certain type, and if it's not recognized, return `JNIInvalidRefType`. So, I'm not sure there should be any `ShouldNotReachHere()` in this code.
>> 
>> We can add an `else` branch that returns `JNIInvalidRefType` though.
>
> The old code would throw `ShouldNotReachHere()` if we did not recognize the handle type:
> https://github.com/openjdk/jdk/blob/d2d1592dd94e897fae6fc4098e43b4fffb6d6750/src/hotspot/share/runtime/jniHandles.cpp#L207
> 
> I think the new code should still keep it, like so:
> 
> 
>  } else if (is_local_handle(thread, handle) || is_frame_handle(thread, handle)) {
>    ...
>  } else {
>    ShouldNotReachHere();
>  }
> 
> 
> That way, if we ever have another handle type, we would hit the `else` branch instead of silently returning `JNIInvalidRefType`. That is, our condition chain would still be exhaustive, catching unexpected values explicitly.

But that just re-introduces the bug? I don't see how we can have both `ShouldNotReachHere()` in the 'else branch' and return `JNIInvalidRefType` for unrecognized handles at the same time.

Not that this function is used to check potentially stale/invalid/corrupt JNI handles, so the input handle can be complete garbage.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1371485862

From jvernee at openjdk.org  Wed Oct 25 10:10:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 10:10:57 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  call fatal without holding code cache lock

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16311/files
  - new: https://git.openjdk.org/jdk/pull/16311/files/06a50e9e..3f2e9d88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=00-01

  Stats: 7 lines in 1 file changed: 4 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16311/head:pull/16311

PR: https://git.openjdk.org/jdk/pull/16311

From shade at openjdk.org  Wed Oct 25 10:11:36 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 25 Oct 2023 10:11:36 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle
In-Reply-To: 
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 <3aLLEdrWdzlYJ4P-vzj0rjkZJOjdVwEzpWaZBGnB-Nc=.a7d99af6-3167-469e-a595-9944b5d7d7ad@github.com>
 
 
 
Message-ID: 

On Wed, 25 Oct 2023 10:05:22 GMT, Jorn Vernee  wrote:

>> The old code would throw `ShouldNotReachHere()` if we did not recognize the handle type:
>> https://github.com/openjdk/jdk/blob/d2d1592dd94e897fae6fc4098e43b4fffb6d6750/src/hotspot/share/runtime/jniHandles.cpp#L207
>> 
>> I think the new code should still keep it, like so:
>> 
>> 
>>  } else if (is_local_handle(thread, handle) || is_frame_handle(thread, handle)) {
>>    ...
>>  } else {
>>    ShouldNotReachHere();
>>  }
>> 
>> 
>> That way, if we ever have another handle type, we would hit the `else` branch instead of silently returning `JNIInvalidRefType`. That is, our condition chain would still be exhaustive, catching unexpected values explicitly.
>
> But that just re-introduces the bug? I don't see how we can have both `ShouldNotReachHere()` in the 'else branch' and return `JNIInvalidRefType` for unrecognized handles at the same time.
> 
> Not that this function is used to check potentially stale/invalid/corrupt JNI handles, so the input handle can be complete garbage.

Ah, d'uh! Not enough coffee today, sorry. Yes, you are right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1371490180

From jvernee at openjdk.org  Wed Oct 25 11:16:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 11:16:54 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle [v2]
In-Reply-To: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
Message-ID: 

> The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.
> 
> While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:
> 
> 
> FATAL ERROR in native method: Bad global or local ref passed to JNI
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
>         at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
>         at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
>         at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
>         at java.lang.reflect.Method.invoke(java.base at 22-internal/Method.java:580...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  explicitly propagate fallback library init failures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16349/files
  - new: https://git.openjdk.org/jdk/pull/16349/files/5ca10654..dd74cdb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16349&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16349&range=00-01

  Stats: 24 lines in 2 files changed: 17 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16349.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16349/head:pull/16349

PR: https://git.openjdk.org/jdk/pull/16349

From jvernee at openjdk.org  Wed Oct 25 11:16:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 11:16:56 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle [v2]
In-Reply-To: <3aLLEdrWdzlYJ4P-vzj0rjkZJOjdVwEzpWaZBGnB-Nc=.a7d99af6-3167-469e-a595-9944b5d7d7ad@github.com>
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 <3aLLEdrWdzlYJ4P-vzj0rjkZJOjdVwEzpWaZBGnB-Nc=.a7d99af6-3167-469e-a595-9944b5d7d7ad@github.com>
Message-ID: 

On Wed, 25 Oct 2023 09:32:42 GMT, Aleksey Shipilev  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   explicitly propagate fallback library init failures
>
> src/java.base/share/native/libfallbackLinker/fallbackLinker.c line 52:
> 
>> 50:     return; // let caller deal with exception
>> 51:   }
>> 52:   LibFallback_class = (*env)->NewGlobalRef(env, LibFallback_class_local);
> 
> I think `NewGlobalRef` can return `nullptr` on OOME: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#NewGlobalRef
> 
> We should check for this too?

I've improved the initialization logic of the surrounding fields as well. Now we explicitly report errors back to the caller (using a boolean return value), which can then throw an exception when the library fails to initialize.

See: https://github.com/openjdk/jdk/pull/16349/commits/dd74cdb9dbe7a05386a18156e7a174c9c8546b1a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1371562428

From jbechberger at openjdk.org  Wed Oct 25 11:33:44 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 25 Oct 2023 11:33:44 GMT
Subject: RFR: JDK-8318736: com/sun/jdi/JdwpOnThrowTest.java failed with
 "transport error 202: bind failed: Address already in use"
Message-ID: 

Fix race condition in debugger port selection, introduced with [JDK-8317920](https://bugs.openjdk.org/browse/JDK-8317920).

Tested on my Mac M1, but it doesn't contain platform-dependent code.

-------------

Commit messages:
 - Fix Debuggee creation

Changes: https://git.openjdk.org/jdk/pull/16358/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16358&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318736
  Stats: 46 lines in 3 files changed: 17 ins; 23 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16358.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16358/head:pull/16358

PR: https://git.openjdk.org/jdk/pull/16358

From ihse at openjdk.org  Wed Oct 25 12:29:32 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 25 Oct 2023 12:29:32 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Oct 2023 23:03:50 GMT, Phil Race  wrote:

>> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use new arrayElementVarHandle method

src/java.base/share/classes/module-info.java line 151:

> 149:     exports jdk.internal.javac to
> 150:         java.compiler,
> 151:          java.desktop, // for ScopedValue

The indentation looks odd..?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1371674366

From jvernee at openjdk.org  Wed Oct 25 13:13:37 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 13:13:37 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: 
References: 
 
Message-ID: <4qn-CzvnxaLi75tXebhHFx50TZAaK092MvUwlmEZxsQ=.dd48a7ff-7f9f-4ea4-93a2-636c6147bcfd@github.com>

On Tue, 24 Oct 2023 15:09:57 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - a -> an
>  - add note to downcallHandle about passing heap segments by-reference

src/hotspot/share/prims/foreignGlobals.cpp line 150:

> 148:     if (signature[i] != T_VOID) {
> 149:       out_regs.push(as_VMStorage(pair.first(), signature[i]));
> 150:     }

Since we only care about registers-sized values. It is safe to ignore upper halves of `T_LONG` and `T_DOUBLE` (i.e. `T_VOID`).

src/hotspot/share/prims/nativeEntryPoint.cpp line 55:

> 53:   for (int i = 0, bt_idx = 0; i < pcount; i++) {
> 54:     oop type_oop = java_lang_invoke_MethodType::ptype(type, i);
> 55:     BasicType bt = java_lang_Class::as_BasicType(type_oop);

We can now see `T_OBJECT` here as well, so we just look at the basic type.

src/hotspot/share/prims/nativeEntryPoint.cpp line 60:

> 58:     if (reg_oop != nullptr) {
> 59:       input_regs.push(ForeignGlobals::parse_vmstorage(reg_oop));
> 60:     }

Some registers are `null`, which indicates that the corresponding value passed to the downcall stub should not be forwarded to the native call, but is instead used directly in the downcall stub (e.g. the offset of an oop).

src/hotspot/share/prims/upcallLinker.cpp line 182:

> 180:   return (jlong) UpcallLinker::make_upcall_stub(
> 181:     mh_j, entry, out_sig_bt, total_out_args, ret_type,
> 182:     abi, conv, needs_return_buffer, checked_cast(ret_buf_size));

Note that we no longer pass the input signature here, which is instead derived from the output signature in the implementation of `make_upcall_stub`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1371738783
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1371734701
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1371736101
PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1371734122

From pminborg at openjdk.org  Wed Oct 25 13:15:45 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 25 Oct 2023 13:15:45 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[]
Message-ID: 

This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.

-------------

Commit messages:
 - Vector access on heap MemorySegments for all array types

Changes: https://git.openjdk.org/jdk/pull/16360/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16360&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318678
  Stats: 269 lines in 41 files changed: 126 ins; 23 del; 120 mod
  Patch: https://git.openjdk.org/jdk/pull/16360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16360/head:pull/16360

PR: https://git.openjdk.org/jdk/pull/16360

From mcimadamore at openjdk.org  Wed Oct 25 13:57:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Oct 2023 13:57:33 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[]
In-Reply-To: 
References: 
Message-ID: <7y0nnTT2jk8nRgJcjTh68NstDzKOUimvxWwbFep5Bek=.0c4378a6-b797-456a-864d-c7f4afcd511f@github.com>

On Wed, 25 Oct 2023 13:08:06 GMT, Per Minborg  wrote:

> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 750:

> 748:     AbstractMemorySegmentImpl requireSegmentConvertibleFor(MemorySegment segment, long offset, int elementByteSize)  {
> 749:         AbstractMemorySegmentImpl ams = (AbstractMemorySegmentImpl) segment;
> 750:         if (ams.maxAlignMask() > 1 && !ams.isAlignedForElement(offset, elementByteSize)) {

I don't think we should only check for maxAlignMask > 1 - you also want to check native segments, right?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 755:

> 753:                     .map(Class::componentType)
> 754:                     .map(Object::toString)
> 755:                     .orElse("?");

orElseThrow?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16360#discussion_r1371805656
PR Review Comment: https://git.openjdk.org/jdk/pull/16360#discussion_r1371806618

From mcimadamore at openjdk.org  Wed Oct 25 14:00:38 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Oct 2023 14:00:38 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[]
In-Reply-To: 
References: 
Message-ID: <9O7THWKXhyhaM3ALfd_v411QgJzgnbgdfbRwveMloss=.2da6300a-f28d-4ac6-ad92-ac6da98bdfca@github.com>

On Wed, 25 Oct 2023 13:08:06 GMT, Per Minborg  wrote:

> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3284:

> 3282:      *         for any lane {@code N} in the vector
> 3283:      * @throws IllegalArgumentException if the memory segment is a heap segment that is
> 3284:      *         not backed by a {@code byte[]} array and if access to the backing array

This seems backwards - e.g. a ByteVector requires an alignment of 1. So I would expect to be able to pass _any_ segment?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16360#discussion_r1371810795

From mcimadamore at openjdk.org  Wed Oct 25 14:03:38 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Oct 2023 14:03:38 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[]
In-Reply-To: 
References: 
Message-ID: 

On Wed, 25 Oct 2023 13:08:06 GMT, Per Minborg  wrote:

> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.

test/jdk/jdk/incubator/vector/AbstractVectorLoadStoreTest.java line 118:

> 116:     private static boolean canBeConverted(IntFunction function, ValueLayout elementLayout) {
> 117:         // Create a sample to analyze
> 118:         MemorySegment s = function.apply(Long.BYTES);

I believe that a good way to test this is the following:
* each vector type operates as having a given element layout - for instance, you can imagine the layout for IntVector to be `JAVA_INT` and so forth
* asking whether you load a segment into a vector is the same as asking whether you can access the segment, at offset 0L, with the layout associated with the vector (see above) - that is if MS::get throws, then vector load should also throw (and viceversa)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16360#discussion_r1371817499

From chegar at openjdk.org  Wed Oct 25 16:38:38 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Wed, 25 Oct 2023 16:38:38 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 25 Oct 2023 14:01:09 GMT, Maurizio Cimadamore  wrote:

>> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.
>
> test/jdk/jdk/incubator/vector/AbstractVectorLoadStoreTest.java line 118:
> 
>> 116:     private static boolean canBeConverted(IntFunction function, ValueLayout elementLayout) {
>> 117:         // Create a sample to analyze
>> 118:         MemorySegment s = function.apply(Long.BYTES);
> 
> I believe that a good way to test this is the following:
> * each vector type operates as having a given element layout - for instance, you can imagine the layout for IntVector to be `JAVA_INT` and so forth
> * asking whether you load a segment into a vector is the same as asking whether you can access the segment, at offset 0L, with the layout associated with the vector (see above) - that is if MS::get throws, then vector load should also throw (and viceversa)

Vectors use and have in their docs, a layout with a byte alignment of 1. e.g. from `IntVector`


 ValueLayout.OfInt ELEMENT_LAYOUT = ValueLayout.JAVA_INT.withByteAlignment(1)


Can the `fromMemorySegment` not just behave similarly? I get that alignment is preferable, but does it need to be enforced?  If so, then maybe the `ELEMENT_LAYOUT` and example in the javadoc needs to be updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16360#discussion_r1372042718

From qamai at openjdk.org  Wed Oct 25 16:51:36 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 25 Oct 2023 16:51:36 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[]
In-Reply-To: 
References: 
Message-ID: 

On Wed, 25 Oct 2023 13:08:06 GMT, Per Minborg  wrote:

> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.

Vector loads and stores are always unaligned, so I don't see the value in forcing the alignment of accesses.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16360#issuecomment-1779674689

From asotona at openjdk.org  Wed Oct 25 16:53:22 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 25 Oct 2023 16:53:22 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v23]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <2HPq6LjW9J4vSEMb6aP4QWrtNJ607vVa-Rw1PyeD4u4=.7f1159bc-c11a-46b4-8825-7fb251d4c904@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 357 commits:

 - fixed jdk.jfr
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - applied javadoc fix suggestions
 - fixed new benchmark
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - removed trailing space
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - package info javadoc improvements
 - removed obsolete exports from BuildMicrobenchmark.gmk
 - Merge branch 'master' into JDK-8308753-preview
 - ... and 347 more: https://git.openjdk.org/jdk/compare/9e98ee67...0587f208

-------------

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=22
  Stats: 32165 lines in 768 files changed: 14622 ins; 14054 del; 3489 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From naoto at openjdk.org  Wed Oct 25 16:53:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Oct 2023 16:53:42 GMT
Subject: Integrated: 8318487: Specification of the ListFormat.equals() method
 can be improved
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 18:40:26 GMT, Naoto Sato  wrote:

> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: a5208870
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/a5208870e16e11514e5b6acae9e933423e54aea0
Stats:     6 lines in 1 file changed: 1 ins; 0 del; 5 mod

8318487: Specification of the ListFormat.equals() method can be improved

Reviewed-by: joehw, rriggs, lancea, iris

-------------

PR: https://git.openjdk.org/jdk/pull/16321

From jlu at openjdk.org  Wed Oct 25 17:15:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Oct 2023 17:15:40 GMT
Subject: Integrated: 8318613: ChoiceFormat patterns are not well tested
In-Reply-To: 
References: 
Message-ID: <5r_j5QFjT3mSOezwinGiDqSTGPCwiHa2PCYDlsRkjWE=.1d14d07f-53ac-446d-ab6b-22dfda0f1086@github.com>

On Mon, 23 Oct 2023 21:15:44 GMT, Justin Lu  wrote:

> Please review this PR which adds a test for ChoiceFormat intended to test a wide range of ChoiceFormat patterns.
> 
> The existing test _Bug4387255_ only tests a singular basic pattern and does not test for incorrect patterns either.
> 
> The new test checks 
> 
> - both correct and incorrect patterns
> - the behavior of incorrect patterns that either throw an IllegalArgumentException or discard the incorrect portion
> - the case of formatting with an empty pattern (that leads to empty limits and formats)

This pull request has now been integrated.

Changeset: 10427c02
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/10427c023a142a24db3c2492977a7233a1afc25d
Stats:     153 lines in 1 file changed: 153 ins; 0 del; 0 mod

8318613: ChoiceFormat patterns are not well tested

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/16324

From jlu at openjdk.org  Wed Oct 25 17:15:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Oct 2023 17:15:43 GMT
Subject: Integrated: 8318186: ChoiceFormat inconsistency between applyPattern()
 and setChoices()
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 17:16:08 GMT, Justin Lu  wrote:

> Please review this PR which clarifies inconsistency between `ChoiceFormat::applyPattern` and `ChoiceFormat::setChoices`.
> 
> A `ChoiceFormat` is composed of limits and formats. `applyPattern()` will throw an exception if limits are not in ascending order, while `setChoices()` will not. This should be clarified in the specification of `applyPattern()`.

This pull request has now been integrated.

Changeset: ca3bdfc0
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/ca3bdfc0c7a74e23329cd9487279992e345b2efd
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8318186: ChoiceFormat inconsistency between applyPattern() and setChoices()

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/16317

From lmesnik at openjdk.org  Wed Oct 25 21:14:55 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 25 Oct 2023 21:14:55 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
Message-ID: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>

The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 

A few tests start failing.

The test
serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.

The test
java/lang/Thread/virtual/ThreadAPI.java
tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.

Test 
test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.

Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.

-------------

Commit messages:
 - 8318839: Update test thread factory to catch all exceptions

Changes: https://git.openjdk.org/jdk/pull/16369/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16369&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318839
  Stats: 18 lines in 4 files changed: 15 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16369.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16369/head:pull/16369

PR: https://git.openjdk.org/jdk/pull/16369

From jvernee at openjdk.org  Wed Oct 25 21:22:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 25 Oct 2023 21:22:23 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: 
References: 
 
Message-ID: <6Ywn5vjecuN2UtqWT6IdM_EyK4xP4foammAeoJCvxx8=.2ab7ba6f-fb37-4620-96b1-9e39b4e939e4@github.com>

On Tue, 24 Oct 2023 15:09:57 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - a -> an
>  - add note to downcallHandle about passing heap segments by-reference

src/hotspot/cpu/x86/downcallLinker_x86_64.cpp line 110:

> 108:   __ mov(rsp, r12); // restore sp
> 109:   __ reinit_heapbase();
> 110: }

This is a minor cleanup to share this code for the three use sites below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1371750211

From rriggs at openjdk.org  Wed Oct 25 22:00:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 25 Oct 2023 22:00:31 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Suggestions to complete the descriptions of the createXXXJavaProcessBuilder methods.

test/lib/jdk/test/lib/process/ProcessTools.java line 505:

> 503:      * @return The ProcessBuilder instance representing the java command.
> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List command) {

Include the same description of other properties that are included in creating the ProcessBuilder...
```     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 520:

> 518:      * @return The ProcessBuilder instance representing the java command.
> 519:      */
> 520:     public static ProcessBuilder createTestJavaProcessBuilder(String... command) {

Include the same description of other properties that are included in creating the ProcessBuilder...

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 538:

> 536:      * it in combination with @requires vm.flagless JTREG
> 537:      * anotation as to not waste energy and test resources.
> 538:      *

Consider adding this description of what this method does.
Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 560:

> 558:      * it in combination with @requires vm.flagless JTREG
> 559:      * anotation as to not waste energy and test resources.
> 560:      *

Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1698308785
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364800
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364171
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372361862
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372362333

From prr at openjdk.org  Wed Oct 25 23:42:08 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Oct 2023 23:42:08 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: 
References: 
Message-ID: 

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15476/files
  - new: https://git.openjdk.org/jdk/pull/15476/files/2f759caf..c05f547d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15476&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15476&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15476/head:pull/15476

PR: https://git.openjdk.org/jdk/pull/15476

From mcimadamore at openjdk.org  Wed Oct 25 23:42:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Oct 2023 23:42:33 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 25 Oct 2023 10:10:57 GMT, Jorn Vernee  wrote:

>> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call fatal without holding code cache lock

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16311#pullrequestreview-1698437302

From david.holmes at oracle.com  Thu Oct 26 02:28:22 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Oct 2023 12:28:22 +1000
Subject: RFC: 8318776: Require supports_cx8 to always be true
In-Reply-To: <517d7c08-e9a6-481a-89e5-2533c5d41724@oracle.com>
References: <517d7c08-e9a6-481a-89e5-2533c5d41724@oracle.com>
Message-ID: 

Adding in porters-dev

On 25/10/2023 5:12 pm, David Holmes wrote:
> From? https://bugs.openjdk.org/browse/JDK-8318776
> 
> Regardless of platform size (32-bit or 64-bit) the Java language has 
> always required that the underlying platform (or the VM) provides a 
> means of performing atomic load and store of 64-bit values, for volatile 
> long and double support.
> 
> Since Java 5 the java.util.concurrent.atomic package introduced APIs 
> that provide a range of atomic operations, the most fundamental being a 
> compare-and-swap (CAS), also known as a compare-exchange, out of which 
> other atomic operations can be constructed if there is no direct 
> platform support. This capability was later extended to the VarHandle 
> API as well.
> 
> While all platforms needed a mechanism for 64-bit load and store, not 
> all platforms support a 64-bit CAS, internally known as cmpxchg8. To 
> address that the supports_cx8 flag was introduced so that on platforms 
> without cmpxchg8 native support, it could be emulated via other 
> techniques e.g. locking. (Note this is not without its own issues as all 
> accesses to the field must be done in a way that is consistent with the 
> use of locking by cmpxchg8 - word-tearing is a real risk).
> 
> Internal to the VM we also have use of lock-free algorithms and atomic 
> operations, with the latter defined via atomic.hpp. Originally in that 
> code we needed to check supports_cx8 for platforms without 64-bit 
> support, but in practice we tended to avoid using 64-bit fields in such 
> cases so we could avoid the complexity of introducing lock-based emulation.
> 
> Unfortunately, when the atomic interface in the VM was templatized and 
> redesigned, it appears that the fact cmpxchg8 may not be available was 
> overlooked and supports_cx8 is not consulted. Consequently if someone 
> introduced an atomic operation on a 64-bit field they would get a 
> linkage error on platforms without cmpxchg8 - so again if this happened 
> we tended to back away from using a 64-bit field.
> 
> Along the way the access API in the VM was introduced, which also 
> provided atomic ops on oops and did consult supports_cx8 with a 
> lock-based fallback.
> 
> We have now reached a point where there are cases where we do want 
> 64-bit atomic operations but we don't want the complexity of dealing 
> with platforms that don't support it. So we want to require that 
> supports_cx8 always be assumed true (the VM could abort at runtime if 
> run on a platform where it is not true) and we can then proceed with 
> 64-bit atomics in the VM and also remove all the lock-based fallbacks in 
> the access API and in the Java APIs.
> 
> The OpenJDK has limited support for 32-bit platforms these days: PPC32 
> was dropped a long time ago; Windows 32-bit is now a deprecated port 
> (but supports cmpxchg8 anyway); leaving only ARM32 as a platform of 
> potential concern. But even then we support cmpxchg8 in all known modern 
> implementations, as described in os_cpu/linux_arm/atomic_linux_arm.hpp:
> 
> /*
>  ?* Atomic long operations on 32-bit ARM
>  ?* ARM v7 supports LDREXD/STREXD synchronization instructions so no 
> problem.
>  ?* ARM < v7 does not have explicit 64 atomic load/store capability.
>  ?* However, gcc emits LDRD/STRD instructions on v5te and LDM/STM on v5t
>  ?* when loading/storing 64 bits.
>  ?* For non-MP machines (which is all we support for ARM < v7)
>  ?* under current Linux distros these instructions appear atomic.
>  ?* See section A3.5.3 of ARM Architecture Reference Manual for ARM v7.
>  ?* Also, for cmpxchg64, if ARM < v7 we check for cmpxchg64 support in the
>  ?* Linux kernel using _kuser_helper_version. See entry-armv.S in the Linux
>  ?* kernel source or kernel_user_helpers.txt in Linux Doc.
>  ?*/
> 
> So the practical reality is that we do not expect to encounter any 
> mainstream OpenJDK platform where we don't in fact have support for 
> cmpxchg8.
> 
> -------
> 
> Before I proceed with this does anyone have any strong and reasonable 
> objections? Is there some platform support aspect that has been overlooked?
> 
> Note the JDK part could be (probably should be) done as a follow up RFE 
> to simplify the review and approval process.
> 
> Thanks,
> David

From jpai at openjdk.org  Thu Oct 26 06:13:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Oct 2023 06:13:37 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
Message-ID: 

On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik  wrote:

> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 
> 
> A few tests start failing.
> 
> The test
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.
> 
> The test
> java/lang/Thread/virtual/ThreadAPI.java
> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.
> 
> Test 
> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.
> 
> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.

Hello Leonid, looking at the changes in this PR, what's being proposed is that when jtreg lauches tests through a virtual thread, then this wrapping code will set a JVM level `UncaughtExceptionHandler` by calling `Thread.setDefaultUncaughtExceptionHandler(...)`. The implementation of this `UncaughtExceptionHandler` calls `System.exit(1)`. Wouldn't that kill the test VM? I think that would then impact everything else including jtreg report generation and such for the test, isn't it? 

I had a look at https://bugs.openjdk.org/browse/JDK-8318839 but it doesn't have enough details to help understand what currently happens when a test launched through a virtual thread from jtreg throws an uncaught exception. How/what gets reported for that test execution?

test/jdk/java/util/concurrent/tck/ThreadTest.java line 79:

> 77:      */
> 78:     public void testGetAndSetDefaultUncaughtExceptionHandler() {
> 79:         assertNull(Thread.getDefaultUncaughtExceptionHandler());

I think this is a very broad change in this test case and either shouldn't be done or should be done conditionally (I can't think of the right condition now because I haven't fully grasped the context of this PR).

test/jtreg_test_thread_factory/src/share/classes/Virtual.java line 37:

> 35:             // The virtual threads don't belong to any group and need global handler.
> 36:             Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
> 37:                     if (e instanceof ThreadDeath) {

`ThreadDeath` has been deprecated for removal since Java 20, so this should no longer be needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1780470987
PR Review Comment: https://git.openjdk.org/jdk/pull/16369#discussion_r1372631138
PR Review Comment: https://git.openjdk.org/jdk/pull/16369#discussion_r1372630017

From xgong at openjdk.org  Thu Oct 26 07:42:35 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 26 Oct 2023 07:42:35 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets.
In-Reply-To: 
References: 
Message-ID: 

On Wed, 25 Oct 2023 04:34:59 GMT, Jatin Bhateja  wrote:

> Hi All,
> 
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
> 
> Following is the summary of changes:-
> 
> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact
> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro.
> 
> 
> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
> 
> 
> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
> 
> 3) Some minor adjustments in existing gather instruction pattens for double/quad words.
> 
> 
> Kindly review and share your feedback.
> 
> 
> Best Regards,
> Jatin

src/hotspot/share/opto/vectorIntrinsics.cpp line 1486:

> 1484:     // Check whether the predicated gather/scatter node is supported by architecture.
> 1485:     VectorMaskUseType mask = (is_scatter || !is_subword_type(elem_bt)) ? (VectorMaskUseType) (VecMaskUseLoad | VecMaskUsePred) : VecMaskUseLoad;
> 1486:     if (!arch_supports_vector(is_scatter ? Op_StoreVectorScatterMasked : Op_LoadVectorGatherMasked, num_elem, elem_bt, mask)) {

What is the difference between subword-type load gather and others? It seems only check `VecMaskUseLoad` is enough for all kinds of masked gather/scatter. Only checking `is_match_rule_supported_vector` for these ops are ok. WDYT?

src/hotspot/share/opto/vectorIntrinsics.cpp line 1599:

> 1597:       if (is_subword_type(elem_bt)) {
> 1598:         Node* index_arr_base = array_element_address(argument(12), argument(13), T_INT);
> 1599:         vload = gvn().transform(new LoadVectorGatherMaskedNode(control(), memory(addr), addr, addr_type, vector_type, index_arr_base, mask, argument(11)));

It's better to define the meaningful variables for `argument(12), argument(13), argument(11)`.

src/hotspot/share/opto/vectornode.hpp line 1001:

> 999:     assert(req() == MemNode::ValueIn + 2, "match_edge expects that last input is in MemNode::ValueIn+1");
> 1000:     if (is_subword_type(vect_type()->is_vect()->element_basic_type())) {
> 1001:       add_req(offset);

`vect_type()->is_vect()`  -> `vt` ?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3062:

> 3060:         // Constant folding should sweep out following conditonal logic.
> 3061:         if (isp.length() > IntVector.SPECIES_PREFERRED.length()) {
> 3062:             lsp = IntVector.SPECIES_PREFERRED;

What happens if the needed index vector length is larger that the max vector length of int type? 
For example, byte vectors with `SPECIES_128`, may needs an index vector with `IntVector.SPECIES_512` species? And on some architectures like NEON, or SVE with 128-bit max vector size, the preferred species is only `SPECIES_128`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1372703788
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1372705631
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1372710351
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1372720580

From goetz at openjdk.org  Thu Oct 26 08:01:41 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Thu, 26 Oct 2023 08:01:41 GMT
Subject: RFR: 8318705: [macos] ProblemList
 java/rmi/registry/multipleRegistries/MultipleRegistries.java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 24 Oct 2023 09:51:20 GMT, Goetz Lindenmaier  wrote:

> ?tipleRegistries.java
> 
> The test fails in our CI with the message listed here. We see both, aarch and x86_64. It happens rarely, but a long time back.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16341#issuecomment-1780602159

From goetz at openjdk.org  Thu Oct 26 08:01:42 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Thu, 26 Oct 2023 08:01:42 GMT
Subject: Integrated: 8318705: [macos] ProblemList
 java/rmi/registry/multipleRegistries/MultipleRegistries.java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 24 Oct 2023 09:51:20 GMT, Goetz Lindenmaier  wrote:

> ?tipleRegistries.java
> 
> The test fails in our CI with the message listed here. We see both, aarch and x86_64. It happens rarely, but a long time back.

This pull request has now been integrated.

Changeset: 37c40a11
Author:    Goetz Lindenmaier 
URL:       https://git.openjdk.org/jdk/commit/37c40a11a78f8b1f290cb04ce5b087904651907e
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8318705: [macos] ProblemList java/rmi/registry/multipleRegistries/MultipleRegistries.java

Reviewed-by: lucy

-------------

PR: https://git.openjdk.org/jdk/pull/16341

From alanb at openjdk.org  Thu Oct 26 08:37:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Oct 2023 08:37:34 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
Message-ID: 

On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik  wrote:

> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 
> 
> A few tests start failing.
> 
> The test
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.
> 
> The test
> java/lang/Thread/virtual/ThreadAPI.java
> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.
> 
> Test 
> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.
> 
> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.

Having a UHE invoke System.exit is surprising. Are you saying that this is only for cases where a test launches a child VM with the thread factory set?

Stepping back a bit. ThreadGroup is legacy and we eventually want it to go away. We've been deprecating and degrading it very slowly over many releases. So I think jtreg will eventually need to change. Right now, it creates AgentVMThreadGroup for agent VM mode so it controls the UHE where it starts the "main thread".  I think it will eventually need to change this to set the system-wide UHE but this means it would handling uncaught exception thrown by "system threads", we may have to audit some of the exception handling if things come out of the woodwork.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1780660022

From pminborg at openjdk.org  Thu Oct 26 09:17:25 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 26 Oct 2023 09:17:25 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[] [v2]
In-Reply-To: 
References: 
Message-ID: <921yYu0_nR0vNTFnKosdaUwXddiZO4BSuVB2LgXg23U=.ebaf87ff-5144-4efc-9d4e-fdee76efd760@github.com>

> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Allow unaligned array access

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16360/files
  - new: https://git.openjdk.org/jdk/pull/16360/files/75bd88ca..4828a98b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16360&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16360&range=00-01

  Stats: 326 lines in 41 files changed: 137 ins; 99 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/16360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16360/head:pull/16360

PR: https://git.openjdk.org/jdk/pull/16360

From pminborg at openjdk.org  Thu Oct 26 09:17:28 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 26 Oct 2023 09:17:28 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[] [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 25 Oct 2023 16:35:30 GMT, Chris Hegarty  wrote:

>> test/jdk/jdk/incubator/vector/AbstractVectorLoadStoreTest.java line 118:
>> 
>>> 116:     private static boolean canBeConverted(IntFunction function, ValueLayout elementLayout) {
>>> 117:         // Create a sample to analyze
>>> 118:         MemorySegment s = function.apply(Long.BYTES);
>> 
>> I believe that a good way to test this is the following:
>> * each vector type operates as having a given element layout - for instance, you can imagine the layout for IntVector to be `JAVA_INT` and so forth
>> * asking whether you load a segment into a vector is the same as asking whether you can access the segment, at offset 0L, with the layout associated with the vector (see above) - that is if MS::get throws, then vector load should also throw (and viceversa)
>
> Vectors use and have in their docs, a layout with a byte alignment of 1. e.g. from `IntVector`
> 
> 
>  ValueLayout.OfInt ELEMENT_LAYOUT = ValueLayout.JAVA_INT.withByteAlignment(1)
> 
> 
> Can the `fromMemorySegment` not just behave similarly? I get that alignment is preferable, but does it need to be enforced?  If so, then maybe the `ELEMENT_LAYOUT` and example in the javadoc needs to be updated.

I've removed the alignment checks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16360#discussion_r1372844356

From chegar at openjdk.org  Thu Oct 26 10:33:32 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Thu, 26 Oct 2023 10:33:32 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[] [v2]
In-Reply-To: <921yYu0_nR0vNTFnKosdaUwXddiZO4BSuVB2LgXg23U=.ebaf87ff-5144-4efc-9d4e-fdee76efd760@github.com>
References: 
 <921yYu0_nR0vNTFnKosdaUwXddiZO4BSuVB2LgXg23U=.ebaf87ff-5144-4efc-9d4e-fdee76efd760@github.com>
Message-ID: 

On Thu, 26 Oct 2023 09:17:25 GMT, Per Minborg  wrote:

>> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow unaligned array access

LGTM

-------------

Marked as reviewed by chegar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16360#pullrequestreview-1699260449

From aturbanov at openjdk.org  Thu Oct 26 11:02:33 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 26 Oct 2023 11:02:33 GMT
Subject: RFR: 8318486: Rename JavaLangAccess.xxNoRepl to xxReportError [v2]
In-Reply-To: 
References: 
 
Message-ID: <1z46SNEeQcxuR4i--NzIoXuqkTybtusqo88Vwfkaz6Q=.a004a3f5-ccac-45ff-a377-cc49a03febc9@github.com>

On Fri, 20 Oct 2023 02:29:15 GMT, Chen Liang  wrote:

>> Please review a patch that renames `JavaLangAccess::xxNoRepl` to `xxReportError` to explicitly indicate these APIs report encoding errors.
>> 
>> The old "NoRepl" suffix presumably means "No Replacement", but it has been misunderstood as "No Replication" (#16209) and misused as an array sharing API in performance optimization patches.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NoRepl -> ReportError

src/java.base/share/classes/java/lang/System.java line 2476:

> 2474:                 return StringCoding.countPositives(bytes, offset, length);
> 2475:             }
> 2476:             public String newStringReportError(byte[] bytes, Charset cs) throws CharacterCodingException  {

Suggestion:

            public String newStringReportError(byte[] bytes, Charset cs) throws CharacterCodingException {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16260#discussion_r1372975296

From dholmes at openjdk.org  Thu Oct 26 12:20:39 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 26 Oct 2023 12:20:39 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 25 Oct 2023 10:10:57 GMT, Jorn Vernee  wrote:

>> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call fatal without holding code cache lock

Is stub allocation the same as other VM C heap exhaustion cases? They will terminate the VM too. Otherwise it would be better report an error and have the Java code thrown OOME.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1781002967

From duke at openjdk.org  Thu Oct 26 12:24:38 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 26 Oct 2023 12:24:38 GMT
Subject: RFR: 8316493: Remove the caching fields in AbstractMap [v10]
In-Reply-To: <3dl3aEeGly12k8ym7G5lK7utYvR9Imq6z9p13Hfshqw=.676beaa9-8bcb-457d-ab25-7f6b229d13fc@github.com>
References: 
 <3dl3aEeGly12k8ym7G5lK7utYvR9Imq6z9p13Hfshqw=.676beaa9-8bcb-457d-ab25-7f6b229d13fc@github.com>
Message-ID: 

On Thu, 19 Oct 2023 13:36:01 GMT, Per Minborg  wrote:

>> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`.
>> 
>> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map.
>> 
>> We need to benchmark this solution to better understand its implications.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove caching in TreeMap

src/java.base/share/classes/java/util/TreeMap.java line 1099:

> 1097:      */
> 1098:     private transient EntrySet entrySet;
> 1099:         private transient NavigableMap descendingMap;

Suggestion:

    private transient NavigableMap descendingMap;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1373080767

From aturbanov at openjdk.org  Thu Oct 26 12:33:44 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 26 Oct 2023 12:33:44 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 24 Oct 2023 15:09:57 GMT, Jorn Vernee  wrote:

>> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call.
>> 
>> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive.
>> 
>> Components of this patch:
>> 
>> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`.
>> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed.
>> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified.
>> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures.
>> - The object/oop + offset is exposed as temporary address to native code.
>> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code).
>> - Only x64 and AArch64 for now.
>> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866
>> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`.
>> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>> 
>> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode.
>> 
>> Numbers for the included benchmark on my machine are:
>> 
>> 
>> Benchmar...
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - a -> an
>  - add note to downcallHandle about passing heap segments by-reference

test/jdk/java/foreign/critical/TestStressAllowHeap.java line 105:

> 103:                 try {
> 104:                     doStep(handle, sequence);
> 105:                 } catch(Throwable t) {

nit
Suggestion:

                } catch (Throwable t) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1373092754

From jvernee at openjdk.org  Thu Oct 26 13:03:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Oct 2023 13:03:34 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <9oYgAEla1_EzWLOQceY3wePQhV3pWBGI7-zlkgMpIeg=.c3f345be-0f90-47d5-812d-fee36ec10642@github.com>

On Thu, 26 Oct 2023 12:17:22 GMT, David Holmes  wrote:

> Is stub allocation the same as other VM C heap exhaustion cases?

I think it depends on the particular case. e.g. `Unsafe::allocateMemory` can also throw OOME.

I think an allocation failure in the particular case of the FFM Linker allocating stubs, is something that we can reasonably report back to the user.

Looking at this again, I realize that we're also allocating a `BufferBlob` when creating the `CodeBuffer`, which is a far bigger allocation, and we never check whether that allocation fails either. I'll have a more thorough look at this.

I agree that bubbling up the allocation failures as OOME would be better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1781077051

From alanb at openjdk.org  Thu Oct 26 14:05:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Oct 2023 14:05:35 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle [v2]
In-Reply-To: 
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 
Message-ID: 

On Wed, 25 Oct 2023 11:16:54 GMT, Jorn Vernee  wrote:

>> The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.
>> 
>> While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:
>> 
>> 
>> FATAL ERROR in native method: Bad global or local ref passed to JNI
>>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
>>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
>>         at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
>>         at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
>>         at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
>>         at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
>>         at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
>>         at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
>>         at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
>>         at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
>>         at java.lang.reflect.Method.invo...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   explicitly propagate fallback library init failures

The changes looks okay to me.

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 49:

> 47:                                 // library failed to initialize. Do not silently mark as unsupported
> 48:                                 throw new ExceptionInInitializerError("Fallback library failed to initialize");
> 49:                             }

It might be better to move this to after the try-catch, if init were to somehow fail with ULE then it suggests something else is wrong.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16349#pullrequestreview-1699749537
PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1373235567

From dnsimon at openjdk.org  Thu Oct 26 14:35:35 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 26 Oct 2023 14:35:35 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 25 Oct 2023 10:10:57 GMT, Jorn Vernee  wrote:

>> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call fatal without holding code cache lock

I agree that avoiding a VM fatal error is preferable, like a recent [change](https://github.com/openjdk/jdk/pull/15970) to make JVMCI RuntimeStub creation failure result in a BailoutException instead of a fatal error.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1781254062

From jvernee at openjdk.org  Thu Oct 26 15:02:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Oct 2023 15:02:46 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle [v3]
In-Reply-To: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
Message-ID: 

> The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.
> 
> While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:
> 
> 
> FATAL ERROR in native method: Bad global or local ref passed to JNI
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
>         at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
>         at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
>         at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
>         at java.lang.reflect.Method.invoke(java.base at 22-internal/Method.java:580...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  move fallback linker initialization outside of try block

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16349/files
  - new: https://git.openjdk.org/jdk/pull/16349/files/dd74cdb9..14ea99a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16349&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16349&range=01-02

  Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16349.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16349/head:pull/16349

PR: https://git.openjdk.org/jdk/pull/16349

From lkorinth at openjdk.org  Thu Oct 26 15:33:38 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 26 Oct 2023 15:33:38 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Would it be okay if we handle the new method documentation in a separate pull request? 

After applying your changes, I also noted that the existing description `The command line will be like: {test.jdk}/bin/java {test.vm.opts} {test.java.opts} cmds` is not only incorrect (or at least incomplete), but now also clashes with the added description. I then removed the sentence, but after I did that I also found out that similar wording exist in `executeTestJvm` and I fear that if I continue to pull strings, I will create more and more changes that you will have opinions on.

Is it all right if we push what we have now, and that I create a new pull requests with these improvements in documentation that are actually not related to the changes in this pull request?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1781359450

From jvernee at openjdk.org  Thu Oct 26 15:56:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Oct 2023 15:56:41 GMT
Subject: Integrated: 8318737: Fallback linker passes bad JNI handle
In-Reply-To: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
Message-ID: <-W8zGHuCucy1GW-SsLzXGi0M_MSOWk5U0M5FEpRpGc0=.5d056081-3f92-4470-b693-5a13e38a3011@github.com>

On Tue, 24 Oct 2023 17:01:35 GMT, Jorn Vernee  wrote:

> The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.
> 
> While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:
> 
> 
> FATAL ERROR in native method: Bad global or local ref passed to JNI
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
>         at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
>         at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
>         at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
>         at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
>         at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
>         at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
>         at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
>         at java.lang.reflect.Method.invoke(java.base at 22-internal/Method.java:580...

This pull request has now been integrated.

Changeset: 3885dc5b
Author:    Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/3885dc5b9acf08dc90397ab02b814bc72d7b4ed5
Stats:     38 lines in 7 files changed: 22 ins; 6 del; 10 mod

8318737: Fallback linker passes bad JNI handle

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/16349

From mcimadamore at openjdk.org  Thu Oct 26 16:18:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 26 Oct 2023 16:18:32 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[] [v2]
In-Reply-To: <921yYu0_nR0vNTFnKosdaUwXddiZO4BSuVB2LgXg23U=.ebaf87ff-5144-4efc-9d4e-fdee76efd760@github.com>
References: 
 <921yYu0_nR0vNTFnKosdaUwXddiZO4BSuVB2LgXg23U=.ebaf87ff-5144-4efc-9d4e-fdee76efd760@github.com>
Message-ID: 

On Thu, 26 Oct 2023 09:17:25 GMT, Per Minborg  wrote:

>> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow unaligned array access

Marked as reviewed by mcimadamore (Reviewer).

On a second look, I agree with the comments. Logically, the vector API is accessing elements using `JAVA_XYZ_UNALIGNED` layouts, which should _always_ succeed. E.g. no alignment exception should ever be possible when doing unaligned access, regardless of whether the segment is on/off heap.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16360#pullrequestreview-1700040222
PR Comment: https://git.openjdk.org/jdk/pull/16360#issuecomment-1781433386

From rriggs at openjdk.org  Thu Oct 26 16:29:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Oct 2023 16:29:40 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

ok, to correct the javadoc in a subsequent PR.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1700061972

From psandoz at openjdk.org  Thu Oct 26 16:48:34 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 26 Oct 2023 16:48:34 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[] [v2]
In-Reply-To: <921yYu0_nR0vNTFnKosdaUwXddiZO4BSuVB2LgXg23U=.ebaf87ff-5144-4efc-9d4e-fdee76efd760@github.com>
References: 
 <921yYu0_nR0vNTFnKosdaUwXddiZO4BSuVB2LgXg23U=.ebaf87ff-5144-4efc-9d4e-fdee76efd760@github.com>
Message-ID: 

On Thu, 26 Oct 2023 09:17:25 GMT, Per Minborg  wrote:

>> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow unaligned array access

We also need to review the intrinsic for load/store found here to ensure, when the hardware supports it, that mixed access is optimized:

https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectorIntrinsics.cpp#L967

I recommend writing a simple benchmark with various forms of mixed access and verify the intrinsics kick in (longer term IR tests would be preferable).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16360#issuecomment-1781482409

From jvernee at openjdk.org  Thu Oct 26 18:11:04 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Oct 2023 18:11:04 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 25 Oct 2023 10:10:57 GMT, Jorn Vernee  wrote:

>> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   call fatal without holding code cache lock

I've uploaded another version that throws a OOME when the allocation of a downcall or upcall stub fails. (on x64 only for now, I'll look at the other platforms as well).

Let me know if that seems better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1781592177

From jvernee at openjdk.org  Thu Oct 26 18:11:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Oct 2023 18:11:06 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <5MgwJQuVNO8OvA86DAx5EIuzq2LA7BDBAvc4CuO2SRg=.9bd9a250-0ed8-4cc4-83e5-77586528be2d@github.com>

On Thu, 26 Oct 2023 18:07:24 GMT, Jorn Vernee  wrote:

>> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw OOME for allocation failures

src/java.base/share/classes/java/lang/foreign/Linker.java line 532:

> 530:      * @throws IllegalArgumentException if an invalid combination of linker options is given.
> 531:      * @throws IllegalCallerException If the caller is in a module that does not have native access enabled.
> 532:      * @throws OutOfMemoryError if the runtime does not have the memory needed to create the downcall handle.

Suggestions for the phrasing here are welcome. I think we should use something that works for both downcall handles and upcall stubs though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1373550409

From jvernee at openjdk.org  Thu Oct 26 18:11:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 26 Oct 2023 18:11:01 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Throw OOME for allocation failures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16311/files
  - new: https://git.openjdk.org/jdk/pull/16311/files/3f2e9d88..6cfd8bed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=01-02

  Stats: 218 lines in 14 files changed: 144 ins; 64 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/16311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16311/head:pull/16311

PR: https://git.openjdk.org/jdk/pull/16311

From mark.reinhold at oracle.com  Thu Oct 26 18:28:41 2023
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Thu, 26 Oct 2023 18:28:41 +0000
Subject: New candidate JEP: 461: Stream Gatherers (Preview)
Message-ID: <20231026182840.66B9064C400@eggemoggin.niobe.net>

https://openjdk.org/jeps/461

  Summary: Enhance the Stream API to support custom intermediate
  operations. This will allow stream pipelines to transform data in ways
  that are not easily achievable with the existing built-in intermediate
  operations. This is a preview API.

- Mark

From dl at openjdk.org  Thu Oct 26 18:33:55 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 26 Oct 2023 18:33:55 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v54]
In-Reply-To: 
References: 
Message-ID: 

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  reduce memory contention

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/84f06bcf..caeb37a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=52-53

  Stats: 80 lines in 1 file changed: 12 ins; 19 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From openjdk at icemanx.nl  Thu Oct 26 19:47:00 2023
From: openjdk at icemanx.nl (Rob Spoor)
Date: Thu, 26 Oct 2023 21:47:00 +0200
Subject: RFE: StringTemplate interpolation with custom function
Message-ID: <3c96b1c1-216e-4fdf-a2d5-1e5f1c6516fc@icemanx.nl>

I've been reading up on string templates, and I think it's a very cool 
feature. However, writing a custom processor can be a lot of copy-paste 
work if you want STR but with some extra translation applied. For 
instance, if I'd want to have a URL encoding processor I would have to 
write everything from scratch.

I think it would be useful to overload interpolate (both static and 
non-static) with a custom Function as additional 
arguments. This would work like STR if that provided String::valueOf as 
function.

With this method, creating a URL encoding processor would be as simple 
as this:

     var urlEncode = template -> template.interpolate(o ->
             URLEncoder.encode(String.valueOf(o), UTF_8));

     var url = urlEncode."https://host/path/\{id}?param=\{value\}";


Likewise, a processor backed by Apache Commons Text's StringEscapeUtils 
would now be just as simple:

     var CSV = template -> template.interpolate(o ->
             StringEscapeUtils.ESCAPE_CSV.translate(String.valueOf(o));

     var csv = CSV."""
             Header1, Header2, Header3
             "\{value1}", "\{value2}", "\{value3}"
             """;


If the JVM allows it, the existing interpolate method can even delegate 
to the new overload providing String::valueOf.

From james.laskey at oracle.com  Thu Oct 26 20:05:37 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 26 Oct 2023 20:05:37 +0000
Subject: RFE: StringTemplate interpolation with custom function
In-Reply-To: <3c96b1c1-216e-4fdf-a2d5-1e5f1c6516fc@icemanx.nl>
References: <3c96b1c1-216e-4fdf-a2d5-1e5f1c6516fc@icemanx.nl>
Message-ID: 

I think I?m missing something. Why wouldn?t you just;

import java.lang.StringTemplate.Processor;

Processor urlEncode = template -> URLEncoder.encode(template.interpolate(), UTF_8));

Processor CSV = template -> StringEscapeUtils.escapeCsv(template.interpolate());


On Oct 26, 2023, at 4:47?PM, Rob Spoor  wrote:

I've been reading up on string templates, and I think it's a very cool feature. However, writing a custom processor can be a lot of copy-paste work if you want STR but with some extra translation applied. For instance, if I'd want to have a URL encoding processor I would have to write everything from scratch.

I think it would be useful to overload interpolate (both static and non-static) with a custom Function as additional arguments. This would work like STR if that provided String::valueOf as function.

With this method, creating a URL encoding processor would be as simple as this:

   var urlEncode = template -> template.interpolate(o ->
           URLEncoder.encode(String.valueOf(o), UTF_8));

   var url = urlEncode."https://host/path/\{id}?param=\{value\}";


Likewise, a processor backed by Apache Commons Text's StringEscapeUtils would now be just as simple:

   var CSV = template -> template.interpolate(o ->
           StringEscapeUtils.ESCAPE_CSV.translate(String.valueOf(o));

   var csv = CSV."""
           Header1, Header2, Header3
           "\{value1}", "\{value2}", "\{value3}"
           """;


If the JVM allows it, the existing interpolate method can even delegate to the new overload providing String::valueOf.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Thu Oct 26 20:11:32 2023
From: duke at openjdk.org (Technici4n)
Date: Thu, 26 Oct 2023 20:11:32 GMT
Subject: RFR: 8314986: Module readability resolution is slow with large
 numbers of automatic modules
In-Reply-To: 
References: 
 
Message-ID: <37GxJHUtExKO5rYRHb16_XZYPqw6vXzMAPB9GBVh--o=.c4431fc5-e3a4-46fc-b63f-2f6109571741@github.com>

On Tue, 26 Sep 2023 14:57:58 GMT, Alan Bateman  wrote:

>> Fixes the issue (hopefully) by resolving automatic modules and automatic module dependencies after propagation of non-automatic transitive dependencies. The module tests run.
>> 
>> I also added a few asserts to validate that the automatic modules don't read themselves (previously this was the case with > 1 automatic module). Should these asserts be added in more places or is this enough?
>> 
>> Alan also mentioned a conflict with the spec, I'm not sure which spec is being referred to. The documentation of `ResolvedModule#reads` states `A possibly-empty unmodifiable set`, implying that the set can be empty.
>> 
>> Finally, `Configuration#reads` states `// The sets stored in the graph are already immutable sets` but that does not seem to be true. Should something be done about this to limit allocation?
>> 
>> Please let me know!
>> Cheers
>
> This issue is on my plate, I will have a PR for this soon. I attached the patch to JDK-8314986 that I was testing in August to skip propagating "requires" through the "requires transitive" edges of the dependence graph. There are several spec issues to work through, the conflict that I mentioned in the JBS issue is that every module is specified to read itself but that is problematic for ResolvedModule::reads to include itself.

Hi @AlanBateman, you are still taking care of this issue for jdk 22, right? Else I can update the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15926#issuecomment-1781826528

From openjdk at icemanx.nl  Thu Oct 26 20:25:12 2023
From: openjdk at icemanx.nl (Rob Spoor)
Date: Thu, 26 Oct 2023 22:25:12 +0200
Subject: RFE: StringTemplate interpolation with custom function
In-Reply-To: 
References: <3c96b1c1-216e-4fdf-a2d5-1e5f1c6516fc@icemanx.nl>
 
Message-ID: <7618982a-6dc6-4d0f-b8bc-c0fbd84ac12d@icemanx.nl>

Because if you URL encode the entire interpolated string the : and / 
inside the URL will also be encoded (to %3A and %2F respectively).

Likewise, the CSV escaping will escape all of the double quotes incorrectly.


On 26/10/2023 22:05, Jim Laskey wrote:
> I think I?m missing something. Why wouldn?t you just;
> 
> import java.lang.StringTemplate.Processor;
> 
> Processor urlEncode = template -> URLEncoder.encode(template.interpolate(), UTF_8));
> 
> Processor CSV = template -> StringEscapeUtils.escapeCsv(template.interpolate());
> 
> 
> On Oct 26, 2023, at 4:47?PM, Rob Spoor  wrote:
> 
> I've been reading up on string templates, and I think it's a very cool feature. However, writing a custom processor can be a lot of copy-paste work if you want STR but with some extra translation applied. For instance, if I'd want to have a URL encoding processor I would have to write everything from scratch.
> 
> I think it would be useful to overload interpolate (both static and non-static) with a custom Function as additional arguments. This would work like STR if that provided String::valueOf as function.
> 
> With this method, creating a URL encoding processor would be as simple as this:
> 
>     var urlEncode = template -> template.interpolate(o ->
>             URLEncoder.encode(String.valueOf(o), UTF_8));
> 
>     var url = urlEncode."https://host/path/\{id}?param=\{value\}";
> 
> 
> Likewise, a processor backed by Apache Commons Text's StringEscapeUtils would now be just as simple:
> 
>     var CSV = template -> template.interpolate(o ->
>             StringEscapeUtils.ESCAPE_CSV.translate(String.valueOf(o));
> 
>     var csv = CSV."""
>             Header1, Header2, Header3
>             "\{value1}", "\{value2}", "\{value3}"
>             """;
> 
> 
> If the JVM allows it, the existing interpolate method can even delegate to the new overload providing String::valueOf.
> 


From james.laskey at oracle.com  Thu Oct 26 20:56:16 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 26 Oct 2023 20:56:16 +0000
Subject: RFE: StringTemplate interpolation with custom function
In-Reply-To: <7618982a-6dc6-4d0f-b8bc-c0fbd84ac12d@icemanx.nl>
References: <3c96b1c1-216e-4fdf-a2d5-1e5f1c6516fc@icemanx.nl>
 
 <7618982a-6dc6-4d0f-b8bc-c0fbd84ac12d@icemanx.nl>
Message-ID: <9928F498-B30F-47DF-B1A3-6008E99BA936@oracle.com>

So you are looking for a different feature - escape sequence suppression. I think that can be simply addressed independently. 

?

> On Oct 26, 2023, at 5:25 PM, Rob Spoor  wrote:
> 
> ?Because if you URL encode the entire interpolated string the : and / inside the URL will also be encoded (to %3A and %2F respectively).
> 
> Likewise, the CSV escaping will escape all of the double quotes incorrectly.
> 
> 
>> On 26/10/2023 22:05, Jim Laskey wrote:
>> I think I?m missing something. Why wouldn?t you just;
>> import java.lang.StringTemplate.Processor;
>> Processor urlEncode = template -> URLEncoder.encode(template.interpolate(), UTF_8));
>> Processor CSV = template -> StringEscapeUtils.escapeCsv(template.interpolate());
>> On Oct 26, 2023, at 4:47?PM, Rob Spoor  wrote:
>> I've been reading up on string templates, and I think it's a very cool feature. However, writing a custom processor can be a lot of copy-paste work if you want STR but with some extra translation applied. For instance, if I'd want to have a URL encoding processor I would have to write everything from scratch.
>> I think it would be useful to overload interpolate (both static and non-static) with a custom Function as additional arguments. This would work like STR if that provided String::valueOf as function.
>> With this method, creating a URL encoding processor would be as simple as this:
>>    var urlEncode = template -> template.interpolate(o ->
>>            URLEncoder.encode(String.valueOf(o), UTF_8));
>>    var url = urlEncode."https://host/path/\{id}?param=\{value\}";
>> Likewise, a processor backed by Apache Commons Text's StringEscapeUtils would now be just as simple:
>>    var CSV = template -> template.interpolate(o ->
>>            StringEscapeUtils.ESCAPE_CSV.translate(String.valueOf(o));
>>    var csv = CSV."""
>>            Header1, Header2, Header3
>>            "\{value1}", "\{value2}", "\{value3}"
>>            """;
>> If the JVM allows it, the existing interpolate method can even delegate to the new overload providing String::valueOf.
> 

From ccheung at openjdk.org  Thu Oct 26 20:59:58 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 26 Oct 2023 20:59:58 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  skip archiving full module graph is there is an incubator module

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16016/files
  - new: https://git.openjdk.org/jdk/pull/16016/files/6c82fde0..f6b2c3d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=03-04

  Stats: 81 lines in 5 files changed: 59 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/16016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16016/head:pull/16016

PR: https://git.openjdk.org/jdk/pull/16016

From bpb at openjdk.org  Thu Oct 26 21:08:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 26 Oct 2023 21:08:41 GMT
Subject: Integrated: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Aug 2023 23:55:35 GMT, Brian Burkhalter  wrote:

> Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.

This pull request has now been integrated.

Changeset: 4a142c3b
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/4a142c3b0831d60b3d5540f58973e8ad3d1304bf
Stats:     13 lines in 2 files changed: 6 ins; 2 del; 5 mod

8274122: java/io/File/createTempFile/SpecialTempFile.java fails in Windows 11

Reviewed-by: lancea, djelinski, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/15460

From ccheung at openjdk.org  Thu Oct 26 21:10:33 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 26 Oct 2023 21:10:33 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Sat, 21 Oct 2023 07:51:42 GMT, Alan Bateman  wrote:

>>> > Yes, because of the following code further up in the same method:
>>> 
>>> I think what you are actually doing here is supporting archiving of the boot layer when the main module transitively depends on an incubator module. We might have to add more tests in this area as it doesn't look like this scenario is tested, at least not with CDS.
>> 
>> Just to add to this. The effect of this change is that a warning won't be emitted if you archive with a boot layer that contains a main module and an incubator module, e.g. main requires jdk.incubator.vector. In other words, `java -Xshare:off -m main` will print the expected warning, `java -Xshare:on -m main` will not.
>
> Another effect of the change to note is that incubator modules will now resolved by default when the initial module is the unnamed module. More explicitly, if you jlink to create a run-time image that contains a main module and an incubator module then `java -Xshare:off -version` will not resolve the incubator moduls (correct behaviour) but `java -Xshare:on -version` will resolve incubator modules (wrong behavior).

I've pushed another update with the following changes:

- in the VM code, skip archiving full module graph if there's an incubator module by checking if the ArchivedBootLayer::archivedBootLayer is available;
- included your suggested code changes in ModuleBootstrap.java;
- added a test scenario with an incubator module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1373816679

From ccheung at openjdk.org  Thu Oct 26 21:24:46 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 26 Oct 2023 21:24:46 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge master
 - skip archiving full module graph is there is an incubator module
 - fix typo
 - simplify some code in modules.cpp
 - comments from Alan and Ioi; add missing @run tag in the test
 - Merge branch 'master' into improve-CDS-module-graph
 - better way to check if a module is a JDK module
 - initial review comments from Ioi
 - 8316969: Improve CDS module graph support for --module option

-------------

Changes: https://git.openjdk.org/jdk/pull/16016/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=05
  Stats: 250 lines in 11 files changed: 236 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16016/head:pull/16016

PR: https://git.openjdk.org/jdk/pull/16016

From lmesnik at openjdk.org  Thu Oct 26 22:37:33 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 26 Oct 2023 22:37:33 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: 
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
 
Message-ID: 

On Thu, 26 Oct 2023 06:09:34 GMT, Jaikiran Pai  wrote:

>> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
>> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 
>> 
>> A few tests start failing.
>> 
>> The test
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
>> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.
>> 
>> The test
>> java/lang/Thread/virtual/ThreadAPI.java
>> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.
>> 
>> Test 
>> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.
>> 
>> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.
>
> test/jtreg_test_thread_factory/src/share/classes/Virtual.java line 37:
> 
>> 35:             // The virtual threads don't belong to any group and need global handler.
>> 36:             Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
>> 37:                     if (e instanceof ThreadDeath) {
> 
> `ThreadDeath` has been deprecated for removal since Java 20, so this should no longer be needed.

It is still used in tests and we should ignore it like jtreg doing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16369#discussion_r1373886743

From dl at openjdk.org  Thu Oct 26 22:38:05 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 26 Oct 2023 22:38:05 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v55]
In-Reply-To: 
References: 
Message-ID: 

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea 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 branch 'openjdk:master' into JDK-8288899
 - reduce memory contention
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge master
 - Ensure liveness for InterruptibleTasks
 - Merge branch 'openjdk:master' into JDK-8288899
 - More cleanup
 - Merge branch 'openjdk:master' into JDK-8288899
 - better window encoding
 - Merge branch 'openjdk:master' into JDK-8288899
 - ... and 93 more: https://git.openjdk.org/jdk/compare/4a142c3b...7c2f9870

-------------

Changes: https://git.openjdk.org/jdk/pull/14301/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=54
  Stats: 4526 lines in 18 files changed: 2460 ins; 664 del; 1402 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From davidalayachew at gmail.com  Thu Oct 26 22:54:51 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 26 Oct 2023 18:54:51 -0400
Subject: New candidate JEP: 461: Stream Gatherers (Preview)
In-Reply-To: <20231026182840.66B9064C400@eggemoggin.niobe.net>
References: <20231026182840.66B9064C400@eggemoggin.niobe.net>
Message-ID: 

Hello Mark,

Thank you for posting this!

This feature will be a blessing, and I can't wait for it to drop.

Could we add more/better documentation for Gatherers::scan? An example
would be nice, and it would also be helpful to highlight the differences
between Gatherers::scan and Gatherers::fold.

Thank you for your time and help!
David Alayachew

On Thu, Oct 26, 2023 at 4:26?PM Mark Reinhold 
wrote:

> https://openjdk.org/jeps/461
>
>   Summary: Enhance the Stream API to support custom intermediate
>   operations. This will allow stream pipelines to transform data in ways
>   that are not easily achievable with the existing built-in intermediate
>   operations. This is a preview API.
>
> - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From davidalayachew at gmail.com  Thu Oct 26 22:55:26 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 26 Oct 2023 18:55:26 -0400
Subject: New candidate JEP: 461: Stream Gatherers (Preview)
In-Reply-To: 
References: <20231026182840.66B9064C400@eggemoggin.niobe.net>
 
Message-ID: 

Alternatively, point me in the direction of the repo, and I'll be happy to
take a crack at it.

On Thu, Oct 26, 2023 at 6:54?PM David Alayachew 
wrote:

> Hello Mark,
>
> Thank you for posting this!
>
> This feature will be a blessing, and I can't wait for it to drop.
>
> Could we add more/better documentation for Gatherers::scan? An example
> would be nice, and it would also be helpful to highlight the differences
> between Gatherers::scan and Gatherers::fold.
>
> Thank you for your time and help!
> David Alayachew
>
> On Thu, Oct 26, 2023 at 4:26?PM Mark Reinhold 
> wrote:
>
>> https://openjdk.org/jeps/461
>>
>>   Summary: Enhance the Stream API to support custom intermediate
>>   operations. This will allow stream pipelines to transform data in ways
>>   that are not easily achievable with the existing built-in intermediate
>>   operations. This is a preview API.
>>
>> - Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lmesnik at openjdk.org  Thu Oct 26 23:04:31 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 26 Oct 2023 23:04:31 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
Message-ID: 

On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik  wrote:

> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 
> 
> A few tests start failing.
> 
> The test
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.
> 
> The test
> java/lang/Thread/virtual/ThreadAPI.java
> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.
> 
> Test 
> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.
> 
> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.

> Hello Leonid, looking at the changes in this PR, what's being proposed is that when jtreg launches tests through a virtual thread, then this wrapping code will set a JVM level UncaughtExceptionHandler by calling Thread.setDefaultUncaughtExceptionHandler(...). The implementation of this UncaughtExceptionHandler calls System.exit(1). Wouldn't that kill the test VM? I think that would then impact everything else including jtreg report generation and such for the test, isn't it?

The jtreg correctly reports such failures. It is expected that JVM might fail.  The only difference is that the reason for failure is System.exit(1) and the exception.

> I had a look at https://bugs.openjdk.org/browse/JDK-8318839 but it doesn't have enough details to help understand what currently happens when a test launched through a virtual thread from jtreg throws an uncaught exception. How/what gets reported for that test execution?

The jtreg correctly catches and reports failures thrown by the main virtual thread. However, it ignores exceptions thrown by any other threads started by the test. 
For platform threads, jtreg uses ThreafGroup (AgentVMThreadGroup or MainThreadGroup)  to report failures in other threads. However, there is no way to use such an approach to catch exceptions for all test threads when virtual threads are used.
See for details:
https://github.com/openjdk/jtreg/blob/ef3865581bdfc55c6315a8538222fc3a91b2b872/src/share/classes/com/sun/javatest/regtest/agent/MainWrapper.java#L72

I have a PR to implement the global exception handling here:
https://github.com/openjdk/jtreg/pull/172

Now it is the only proposal and might take a long time to complete it. So the current fix helps us to find issues with the virtual thread test factory until jtreg is fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1782021953

From lmesnik at openjdk.org  Thu Oct 26 23:08:32 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 26 Oct 2023 23:08:32 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: 
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
 
Message-ID: <0pXMnIBqKI4R89gdQ6JOTWTzFkKc2ncwdzbzc6o2nlA=.3288cbe5-e389-4b95-ad79-2283a363d7d2@github.com>

On Thu, 26 Oct 2023 08:34:39 GMT, Alan Bateman  wrote:

> Having a UHE invoke System.exit is surprising. Are you saying that this is only for cases where a test launches a child VM with the thread factory set?

It is for cases when the test is started in a virtual thread. I don't see a better way to process unexpected exceptions right now. I don't want to complicate the interface between jtreg and the plugin for this temporary fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1782028651

From lmesnik at openjdk.org  Thu Oct 26 23:11:33 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 26 Oct 2023 23:11:33 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: 
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
 
Message-ID: <7vUtv8R_TYLX6ECx5YiBSh7Vc59LF2rOFXjUNXE2Fpc=.b4dec742-93d8-405b-8594-45092abf9315@github.com>

On Thu, 26 Oct 2023 08:34:39 GMT, Alan Bateman  wrote:

> Stepping back a bit. ThreadGroup is legacy and we eventually want it to go away. We've been deprecating and degrading it very slowly over many releases. So I think jtreg will eventually need to change. Right now, it creates AgentVMThreadGroup for agent VM mode so it controls the UHE where it starts the "main thread". I think it will eventually need to change this to set the system-wide UHE but this means it would handling uncaught exception thrown by "system threads", we may have to audit some of the exception handling if things come out of the woodwork.

I think we shouldn't allow any unhandled exceptions in system threads also. This might just hide issues. The tests that might erase such exceptions should be written to for VM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1782033148

From ysuenaga at openjdk.org  Fri Oct 27 03:51:44 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 27 Oct 2023 03:51:44 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: <6Ywn5vjecuN2UtqWT6IdM_EyK4xP4foammAeoJCvxx8=.2ab7ba6f-fb37-4620-96b1-9e39b4e939e4@github.com>
References: 
 
 <6Ywn5vjecuN2UtqWT6IdM_EyK4xP4foammAeoJCvxx8=.2ab7ba6f-fb37-4620-96b1-9e39b4e939e4@github.com>
Message-ID: 

On Wed, 25 Oct 2023 13:18:33 GMT, Jorn Vernee  wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - a -> an
>>  - add note to downcallHandle about passing heap segments by-reference
>
> src/hotspot/cpu/x86/downcallLinker_x86_64.cpp line 110:
> 
>> 108:   __ mov(rsp, r12); // restore sp
>> 109:   __ reinit_heapbase();
>> 110: }
> 
> This is a minor cleanup to share this code for the three use sites below.

Question: `r12` does not need to remember?

According to [CallingSequences in OpenJDK Wiki](https://wiki.openjdk.org/display/HotSpot/CallingSequences), `r12` may be reserved for HeapBase if COOP is enabled.  
(`r12` is also used in another places in downcallLinker_x86_64.cpp without restoring...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1374042333

From dholmes at openjdk.org  Fri Oct 27 04:56:32 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 27 Oct 2023 04:56:32 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v3]
In-Reply-To: <5MgwJQuVNO8OvA86DAx5EIuzq2LA7BDBAvc4CuO2SRg=.9bd9a250-0ed8-4cc4-83e5-77586528be2d@github.com>
References: 
 
 <5MgwJQuVNO8OvA86DAx5EIuzq2LA7BDBAvc4CuO2SRg=.9bd9a250-0ed8-4cc4-83e5-77586528be2d@github.com>
Message-ID: 

On Thu, 26 Oct 2023 18:07:24 GMT, Jorn Vernee  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Throw OOME for allocation failures
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 532:
> 
>> 530:      * @throws IllegalArgumentException if an invalid combination of linker options is given.
>> 531:      * @throws IllegalCallerException If the caller is in a module that does not have native access enabled.
>> 532:      * @throws OutOfMemoryError if the runtime does not have the memory needed to create the downcall handle.
> 
> Suggestions for the phrasing here are welcome. I think we should use something that works for both downcall handles and upcall stubs though.

OOME is pretty much understood to be possible anywhere, given it is a VirtualMachineError. We often do not document it explicitly. The risk with documenting it is that it gives the impression that other methods, which don't document it, can never throw it. A rough grep for `@throws OutOfMemoryError` reveals only 12 classes in java.base that explicitly document this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1374071184

From jbhateja at openjdk.org  Fri Oct 27 05:12:34 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Oct 2023 05:12:34 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets.
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 26 Oct 2023 07:21:28 GMT, Xiaohong Gong  wrote:

>> Hi All,
>> 
>> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
>> 
>> Following is the summary of changes:-
>> 
>> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact
>> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro.
>> 
>> 
>> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
>> 
>> 
>> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
>> 
>> 3) Some minor adjustments in existing gather instruction pattens for double/quad words.
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> 
>> Best Regards,
>> Jatin
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1486:
> 
>> 1484:     // Check whether the predicated gather/scatter node is supported by architecture.
>> 1485:     VectorMaskUseType mask = (is_scatter || !is_subword_type(elem_bt)) ? (VectorMaskUseType) (VecMaskUseLoad | VecMaskUsePred) : VecMaskUseLoad;
>> 1486:     if (!arch_supports_vector(is_scatter ? Op_StoreVectorScatterMasked : Op_LoadVectorGatherMasked, num_elem, elem_bt, mask)) {
> 
> What is the difference between subword-type load gather and others? It seems only check `VecMaskUseLoad` is enough for all kinds of masked gather/scatter. Only checking `is_match_rule_supported_vector` for these ops are ok. WDYT?

sub-word gather do not emit any predicated instructions, thus only VectorMaskUseLoad is relevant in this context, however AVX512 and SVE does have a direct predicated gather instructions for 32/64 bit types.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3062:
> 
>> 3060:         // Constant folding should sweep out following conditonal logic.
>> 3061:         if (isp.length() > IntVector.SPECIES_PREFERRED.length()) {
>> 3062:             lsp = IntVector.SPECIES_PREFERRED;
> 
> What happens if the needed index vector length is larger that the max vector length of int type? 
> For example, byte vectors with `SPECIES_128`, may needs an index vector with `IntVector.SPECIES_512` species? And on some architectures like NEON, or SVE with 128-bit max vector size, the preferred species is only `SPECIES_128`.

For x86 backend implementation we emit a gather loop hence index species is not used for sub-word, I am performing the index out of bound in a loop which operate a max integer vector granularity supported by target.
https://github.com/openjdk/jdk/pull/16354/files#diff-13cc2d6ec18e487ddae05cda671bdb6bb7ffd42ff7bc51a2e00c8c5e622bd55dR3641

Because there is cap on max integral vector size, thus for targets supporting direct sub-word gather instruction will have to emit an instruction sequence comprising of partial indexMap loads into integral vectors and issue multiple gather operations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1374077991
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1374077927

From dholmes at openjdk.org  Fri Oct 27 05:32:40 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 27 Oct 2023 05:32:40 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle [v3]
In-Reply-To: 
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 
Message-ID: 

On Thu, 26 Oct 2023 15:02:46 GMT, Jorn Vernee  wrote:

>> The result of `FindClass` is a local JNI handle (in `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we need to wrap the return value of `FindClass` in a global reference when storing it inside fallbackLinker.c.
>> 
>> While investigating this, I also noticed an existing bug in `JNIHandles::handle_type`. This method is used from the implementation of `GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code. The former specifies that `JNIInvalidRefType` is a valid return value, and the latter compares the result against `JNIInvalidRefType`. However, if the handle is not any valid type, the implementation bottoms out in a `ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return `JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain fall through to just returning the default result, which is `JNIInvalidRefType`. In that case, I observe the expected stack trace when running with `-Xcheck:jni`. For example:
>> 
>> 
>> FATAL ERROR in native method: Bad global or local ref passed to JNI
>>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/Native Method)
>>         at jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base at 22-internal/LibFallback.java:94)
>>         at jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base at 22-internal/FallbackLinker.java:197)
>>         at java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base at 22-internal/LambdaForm$DMH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base at 22-internal/LambdaForm$MH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base at 22-internal/LambdaForm$MH)
>>         at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
>>         at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
>>         at java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base at 22-internal/LambdaForm$DMH)
>>         at java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base at 22-internal/LambdaForm$MH)
>>         at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 22-internal/Invokers$Holder)
>>         at jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base at 22-internal/DirectMethodHandleAccessor.java:154)
>>         at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base at 22-internal/DirectMethodHandleAccessor.java:103)
>>         at java.lang.reflect.Method.invo...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move fallback linker initialization outside of try block

One minor nit but the hotspot changes, aposteri, look good.

@JornVernee please don't forget that all non-trivial (as defined by the dev guide) hotspot changes require at least 2 reviews and a 24 hour wait before integration. Thanks.

src/hotspot/share/runtime/jniHandles.cpp line 203:

> 201:     }
> 202:   } else if (is_local_handle(thread, handle) || is_frame_handle(thread, handle)) {
> 203:     // Not in global storage.  Might be a local handle.

The comment doesn't really make sense after the condition is checked.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16349#pullrequestreview-1701022199
PR Comment: https://git.openjdk.org/jdk/pull/16349#issuecomment-1782316338
PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1374088191

From jbhateja at openjdk.org  Fri Oct 27 05:47:07 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Oct 2023 05:47:07 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi All,
> 
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
> 
> Following is the summary of changes:-
> 
> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact
> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro.
> 
> 
> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
> 
> 
> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
> 
> 3) Some minor adjustments in existing gather instruction pattens for double/quad words.
> 
> 
> Kindly review and share your feedback.
> 
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolution.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16354/files
  - new: https://git.openjdk.org/jdk/pull/16354/files/1893049c..d0d6f455

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=00-01

  Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16354/head:pull/16354

PR: https://git.openjdk.org/jdk/pull/16354

From dholmes at openjdk.org  Fri Oct 27 05:58:32 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 27 Oct 2023 05:58:32 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
Message-ID: <1FD6HX13l4t-q6wuU-zlMVcS6CDPCTB3sEHwO4HzhLQ=.8024ce47-f9cc-4b2f-9702-752178546975@github.com>

On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik  wrote:

> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 
> 
> A few tests start failing.
> 
> The test
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.
> 
> The test
> java/lang/Thread/virtual/ThreadAPI.java
> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.
> 
> Test 
> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.
> 
> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.

Not at all sure this is the right approach ... an exception in an arbitrary thread should not terminate the VM. Sometimes we might expect a thread to terminate by exception.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16369#pullrequestreview-1701043216

From dholmes at openjdk.org  Fri Oct 27 05:58:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 27 Oct 2023 05:58:33 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: 
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
 
 
Message-ID: 

On Thu, 26 Oct 2023 22:34:24 GMT, Leonid Mesnik  wrote:

>> test/jtreg_test_thread_factory/src/share/classes/Virtual.java line 37:
>> 
>>> 35:             // The virtual threads don't belong to any group and need global handler.
>>> 36:             Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
>>> 37:                     if (e instanceof ThreadDeath) {
>> 
>> `ThreadDeath` has been deprecated for removal since Java 20, so this should no longer be needed.
>
> It is still used in tests and we should ignore it like jtreg doing.

Shouldn't this code first retrieve the current default exception handler, and then check whether t is a virtual thread, and if so handle the exception as appropriate (not sure System.exit is appropriate ..). Then for non-virtual threads it delegates to the previous default handler.

final UncaughtExceptionHandler originalUEH = Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
        if (t.isVirtual()) {
            // ...
        } else {
            originalUEH.uncaughtException(t, e);
        }
});

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16369#discussion_r1374102902

From alanb at openjdk.org  Fri Oct 27 06:37:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Oct 2023 06:37:30 GMT
Subject: RFR: 8314986: Module readability resolution is slow with large
 numbers of automatic modules
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 26 Sep 2023 14:57:58 GMT, Alan Bateman  wrote:

>> Fixes the issue (hopefully) by resolving automatic modules and automatic module dependencies after propagation of non-automatic transitive dependencies. The module tests run.
>> 
>> I also added a few asserts to validate that the automatic modules don't read themselves (previously this was the case with > 1 automatic module). Should these asserts be added in more places or is this enough?
>> 
>> Alan also mentioned a conflict with the spec, I'm not sure which spec is being referred to. The documentation of `ResolvedModule#reads` states `A possibly-empty unmodifiable set`, implying that the set can be empty.
>> 
>> Finally, `Configuration#reads` states `// The sets stored in the graph are already immutable sets` but that does not seem to be true. Should something be done about this to limit allocation?
>> 
>> Please let me know!
>> Cheers
>
> This issue is on my plate, I will have a PR for this soon. I attached the patch to JDK-8314986 that I was testing in August to skip propagating "requires" through the "requires transitive" edges of the dependence graph. There are several spec issues to work through, the conflict that I mentioned in the JBS issue is that every module is specified to read itself but that is problematic for ResolvedModule::reads to include itself.

> Hi @AlanBateman, you are still taking care of this issue for jdk 22, right? Else I can update the PR.

Yes, it's on my list.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15926#issuecomment-1782374864

From xgong at openjdk.org  Fri Oct 27 06:44:31 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 27 Oct 2023 06:44:31 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 27 Oct 2023 05:09:23 GMT, Jatin Bhateja  wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 1486:
>> 
>>> 1484:     // Check whether the predicated gather/scatter node is supported by architecture.
>>> 1485:     VectorMaskUseType mask = (is_scatter || !is_subword_type(elem_bt)) ? (VectorMaskUseType) (VecMaskUseLoad | VecMaskUsePred) : VecMaskUseLoad;
>>> 1486:     if (!arch_supports_vector(is_scatter ? Op_StoreVectorScatterMasked : Op_LoadVectorGatherMasked, num_elem, elem_bt, mask)) {
>> 
>> What is the difference between subword-type load gather and others? It seems only check `VecMaskUseLoad` is enough for all kinds of masked gather/scatter. Only checking `is_match_rule_supported_vector` for these ops are ok. WDYT?
>
> sub-word gather do not emit any predicated instructions, thus only VectorMaskUseLoad is relevant in this context, however AVX512 and SVE does have a direct predicated gather instructions for 32/64 bit types.

I see, thanks! `VecMaskUsePred` is added to check `match_rule_supported_vector_masked` for normal vector ops. That's because we may add an additional mask input for those vector ops. But `Load|StoreVectorScatterMasked` are different. They point to the masked operations no matter how they are implemented. So just `VecMaskUseLoad` is fine for all these two ops for me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1374135147

From pminborg at openjdk.org  Fri Oct 27 07:25:41 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 27 Oct 2023 07:25:41 GMT
Subject: Withdrawn: 8317993: Add capturing factories to classes in
 java.util.function package
In-Reply-To: 
References: 
Message-ID: 

On Tue, 17 Oct 2023 08:05:09 GMT, Per Minborg  wrote:

> This PR proposes to add a number of "capturing factories" in classes in the `java.util.function` package.
> 
> The PR additionally (an optionally) proposes to add a new function `UnaryOperator::andThenUnary` to allow composition while retaining the `UnaryOperator` type.
> 
> With the new changes, it is possible to write code like this (example from `java.util.function.Function`):
> 
> 
> // Resolve ambiguity
> var function = Function.of(String::isEmpty); // Function
> var predicate = Predicate.of(String::isEmpty); // Predicate
> 
> // Fluent composition
> var chained = Function.of(String::length)       // Function
>                    .andThen(Integer::byteValue);      // Function
> 
> 
> Please see the original bug report for a comprehensive description of these proposed changes.
> 
> Note: It is not the objective to promote `var` declaration or to prevent previous ways of capturing lambdas and method references. The comments in the code above is for explaining the binding and once that becomes obvious, such comments are likely to not appear in real code. Users that prefers having a normal type declaration can still do that.
> 
> Note: Functional interfaces of primitives have not been considered (in this round). Otherwise, functional interfaces that might be ambiguous or that supports composition have been included. Hence, `Supplier` did not get a factory method.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/16213

From xgong at openjdk.org  Fri Oct 27 08:07:32 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 27 Oct 2023 08:07:32 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 27 Oct 2023 05:09:15 GMT, Jatin Bhateja  wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3062:
>> 
>>> 3060:         // Constant folding should sweep out following conditonal logic.
>>> 3061:         if (isp.length() > IntVector.SPECIES_PREFERRED.length()) {
>>> 3062:             lsp = IntVector.SPECIES_PREFERRED;
>> 
>> What happens if the needed index vector length is larger that the max vector length of int type? 
>> For example, byte vectors with `SPECIES_128`, may needs an index vector with `IntVector.SPECIES_512` species? And on some architectures like NEON, or SVE with 128-bit max vector size, the preferred species is only `SPECIES_128`.
>
> For x86 backend implementation we emit a gather loop hence index species is not used for sub-word, I am performing the index out of bound in a loop which operate a max integer vector granularity supported by target.
> https://github.com/openjdk/jdk/pull/16354/files#diff-13cc2d6ec18e487ddae05cda671bdb6bb7ffd42ff7bc51a2e00c8c5e622bd55dR3641
> 
> Because there is cap on max integral vector size, thus for targets supporting direct sub-word gather instruction will have to emit an instruction sequence comprising of partial indexMap loads into integral vectors and issue multiple gather operations.

I see, thanks for the explanation! It's different from SVE, which the index should be an int vector with the same length of the target vector.  We have to generate the index vectors. So the array length check to the given index map is necessary in java side.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1374215257

From lkorinth at openjdk.org  Fri Oct 27 08:50:47 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 08:50:47 GMT
Subject: Integrated: 8315097: Rename createJavaProcessBuilder
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth  wrote:

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

This pull request has now been integrated.

Changeset: d52a995f
Author:    Leo Korinth 
URL:       https://git.openjdk.org/jdk/commit/d52a995f35de26c2cc4074297a75141e4a363e1b
Stats:     1574 lines in 560 files changed: 44 ins; 10 del; 1520 mod

8315097: Rename createJavaProcessBuilder

Reviewed-by: lmesnik, dholmes, rriggs, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/15452

From mcimadamore at openjdk.org  Fri Oct 27 08:52:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 27 Oct 2023 08:52:33 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v3]
In-Reply-To: 
References: 
 
 <5MgwJQuVNO8OvA86DAx5EIuzq2LA7BDBAvc4CuO2SRg=.9bd9a250-0ed8-4cc4-83e5-77586528be2d@github.com>
 
Message-ID: 

On Fri, 27 Oct 2023 04:54:04 GMT, David Holmes  wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 532:
>> 
>>> 530:      * @throws IllegalArgumentException if an invalid combination of linker options is given.
>>> 531:      * @throws IllegalCallerException If the caller is in a module that does not have native access enabled.
>>> 532:      * @throws OutOfMemoryError if the runtime does not have the memory needed to create the downcall handle.
>> 
>> Suggestions for the phrasing here are welcome. I think we should use something that works for both downcall handles and upcall stubs though.
>
> OOME is pretty much understood to be possible anywhere, given it is a VirtualMachineError. We often do not document it explicitly. The risk with documenting it is that it gives the impression that other methods, which don't document it, can never throw it. A rough grep for `@throws OutOfMemoryError` reveals only 15 classes in java.base that explicitly document this.

Taking inspiration from other methods that throw this exception, maybe something like this might work:

`if the downcall method handle cannot be allocated by the Linker`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1374268730

From mcimadamore at openjdk.org  Fri Oct 27 08:55:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 27 Oct 2023 08:55:33 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v3]
In-Reply-To: 
References: 
 
 <5MgwJQuVNO8OvA86DAx5EIuzq2LA7BDBAvc4CuO2SRg=.9bd9a250-0ed8-4cc4-83e5-77586528be2d@github.com>
 
Message-ID: 

On Fri, 27 Oct 2023 04:54:04 GMT, David Holmes  wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 532:
>> 
>>> 530:      * @throws IllegalArgumentException if an invalid combination of linker options is given.
>>> 531:      * @throws IllegalCallerException If the caller is in a module that does not have native access enabled.
>>> 532:      * @throws OutOfMemoryError if the runtime does not have the memory needed to create the downcall handle.
>> 
>> Suggestions for the phrasing here are welcome. I think we should use something that works for both downcall handles and upcall stubs though.
>
> OOME is pretty much understood to be possible anywhere, given it is a VirtualMachineError. We often do not document it explicitly. The risk with documenting it is that it gives the impression that other methods, which don't document it, can never throw it. A rough grep for `@throws OutOfMemoryError` reveals only 15 classes in java.base that explicitly document this.

That said, I also agree with @dholmes-ora - e.g. I'm not sure how much OOME is important to document here, since it reflects an internal state of the JVM, rather than something the client can do something about.

E.g. if you create an allocator with `SegmentAllocator::slicingAllocator`, at some point you are going to run out of space in the underlying segment, so it makes sense to report failures (and to document why that happens). But in this case the documentation is going to be very vague, and I don't think it provides a lot of value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1374271936

From lkorinth at openjdk.org  Fri Oct 27 09:00:48 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 09:00:48 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Thanks, see:
https://bugs.openjdk.org/browse/JDK-8318962

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1782552641

From jvernee at openjdk.org  Fri Oct 27 09:11:42 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 27 Oct 2023 09:11:42 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle [v3]
In-Reply-To: 
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 
 
Message-ID: 

On Fri, 27 Oct 2023 05:26:47 GMT, David Holmes  wrote:

> @JornVernee please don't forget that all non-trivial (as defined by the dev guide) hotspot changes require at least 2 reviews and a 24 hour wait before integration. Thanks.

Right, sorry. I think I confused this PR with https://github.com/openjdk/jdk/pull/16311 for a moment, and got in my head that shipilev had already approved.

> One minor nit but the hotspot changes, aposteri, look good.

Do you want me to create a separate PR to remove the comment?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16349#issuecomment-1782568248
PR Comment: https://git.openjdk.org/jdk/pull/16349#issuecomment-1782568682

From jvernee at openjdk.org  Fri Oct 27 09:20:44 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 27 Oct 2023 09:20:44 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: 
References: 
 
 <6Ywn5vjecuN2UtqWT6IdM_EyK4xP4foammAeoJCvxx8=.2ab7ba6f-fb37-4620-96b1-9e39b4e939e4@github.com>
 
Message-ID: 

On Fri, 27 Oct 2023 03:49:17 GMT, Yasumasa Suenaga  wrote:

>> src/hotspot/cpu/x86/downcallLinker_x86_64.cpp line 110:
>> 
>>> 108:   __ mov(rsp, r12); // restore sp
>>> 109:   __ reinit_heapbase();
>>> 110: }
>> 
>> This is a minor cleanup to share this code for the three use sites below.
>
> Question: `r12` does not need to remember?
> 
> According to [CallingSequences in OpenJDK Wiki](https://wiki.openjdk.org/display/HotSpot/CallingSequences), `r12` may be reserved for HeapBase if COOP is enabled.  
> (`r12` is also used in another places in downcallLinker_x86_64.cpp without restoring...)

You mean `reinit_heapbase` can be removed? I'm not sure whether the caller expects it to be preserved.

Note that `r12` is used in this case to save and restore `rsp`. This is needed since we access data in the frame relative to `rsp`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1374300821

From jvernee at openjdk.org  Fri Oct 27 09:22:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 27 Oct 2023 09:22:33 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v3]
In-Reply-To: 
References: 
 
 <5MgwJQuVNO8OvA86DAx5EIuzq2LA7BDBAvc4CuO2SRg=.9bd9a250-0ed8-4cc4-83e5-77586528be2d@github.com>
 
 
Message-ID: 

On Fri, 27 Oct 2023 08:52:42 GMT, Maurizio Cimadamore  wrote:

>> OOME is pretty much understood to be possible anywhere, given it is a VirtualMachineError. We often do not document it explicitly. The risk with documenting it is that it gives the impression that other methods, which don't document it, can never throw it. A rough grep for `@throws OutOfMemoryError` reveals only 15 classes in java.base that explicitly document this.
>
> That said, I also agree with @dholmes-ora - e.g. I'm not sure how much OOME is important to document here, since it reflects an internal state of the JVM, rather than something the client can do something about.
> 
> E.g. if you create an allocator with `SegmentAllocator::slicingAllocator`, at some point you are going to run out of space in the underlying segment, so it makes sense to report failures (and to document why that happens). But in this case the documentation is going to be very vague, and I don't think it provides a lot of value.

Ok. I figured it was similar to Unsafe::allocateMemory, which also documents to OOME. But then again, the user is not directly interested in memory in this case.

I"ll remove these `@throws` tags then

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1374303739

From lkorinth at openjdk.org  Fri Oct 27 09:54:50 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 09:54:50 GMT
Subject: Integrated: 8318964: Fix build failures caused by 8315097
Message-ID: 

Update method name after huge renaming conflict

-------------

Commit messages:
 - 8318964: Fix build failures caused by 8315097

Changes: https://git.openjdk.org/jdk/pull/16395/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16395&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318964
  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16395/head:pull/16395

PR: https://git.openjdk.org/jdk/pull/16395

From aboldtch at openjdk.org  Fri Oct 27 09:54:51 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 27 Oct 2023 09:54:51 GMT
Subject: Integrated: 8318964: Fix build failures caused by 8315097
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 09:48:00 GMT, Leo Korinth  wrote:

> Update method name after huge renaming conflict

Marked as reviewed by aboldtch (Reviewer).

Trivial fix.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16395#pullrequestreview-1701406738
PR Comment: https://git.openjdk.org/jdk/pull/16395#issuecomment-1782626722

From lkorinth at openjdk.org  Fri Oct 27 09:54:52 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 09:54:52 GMT
Subject: Integrated: 8318964: Fix build failures caused by 8315097
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 09:48:00 GMT, Leo Korinth  wrote:

> Update method name after huge renaming conflict

Thanks!!!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16395#issuecomment-1782627439

From rcastanedalo at openjdk.org  Fri Oct 27 09:54:52 2023
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 27 Oct 2023 09:54:52 GMT
Subject: Integrated: 8318964: Fix build failures caused by 8315097
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 09:48:00 GMT, Leo Korinth  wrote:

> Update method name after huge renaming conflict

Looks good and trivial.

-------------

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16395#pullrequestreview-1701407759

From lkorinth at openjdk.org  Fri Oct 27 09:54:52 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 09:54:52 GMT
Subject: Integrated: 8318964: Fix build failures caused by 8315097
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 09:48:00 GMT, Leo Korinth  wrote:

> Update method name after huge renaming conflict

This pull request has now been integrated.

Changeset: b9dcd4b7
Author:    Leo Korinth 
URL:       https://git.openjdk.org/jdk/commit/b9dcd4b74138dd77faa46525f101b985248fffc5
Stats:     5 lines in 5 files changed: 0 ins; 0 del; 5 mod

8318964: Fix build failures caused by 8315097

Reviewed-by: aboldtch, rcastanedalo

-------------

PR: https://git.openjdk.org/jdk/pull/16395

From jvernee at openjdk.org  Fri Oct 27 09:56:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 27 Oct 2023 09:56:01 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.

Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:

 - remove unused imports
 - remove flaky downcall stub oome test
 - remove @throws

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16311/files
  - new: https://git.openjdk.org/jdk/pull/16311/files/6cfd8bed..52e875eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=02-03

  Stats: 39 lines in 2 files changed: 0 ins; 39 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16311/head:pull/16311

PR: https://git.openjdk.org/jdk/pull/16311

From jvernee at openjdk.org  Fri Oct 27 09:56:03 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 27 Oct 2023 09:56:03 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 26 Oct 2023 18:11:01 GMT, Jorn Vernee  wrote:

>> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw OOME for allocation failures

I've also removed the test that tries to trigger an OOME when allocating downcall stubs. It seems not really possible to isolate that particular code path (unless a direct whitebox API is added maybe, but that also kinda defeats the purpose of testing), leading to a flaky test. I've left the test for upcall stubs, as that seems to work well enough (but, might need to drop that as well).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1782629405

From dl at openjdk.org  Fri Oct 27 10:11:51 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 27 Oct 2023 10:11:51 GMT
Subject: Integrated: 8288899:
 java/util/concurrent/ExecutorService/CloseTest.java failed with
 "InterruptedException: sleep interrupted"
In-Reply-To: 
References: 
Message-ID: 

On Sat, 3 Jun 2023 14:08:02 GMT, Doug Lea 
 wrote:

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

This pull request has now been integrated.

Changeset: 667cca9d
Author:    Doug Lea 

URL:       https://git.openjdk.org/jdk/commit/667cca9d7aef1ff4abe630cefaac34c0b1646925
Stats:     4526 lines in 18 files changed: 2460 ins; 664 del; 1402 mod

8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted"

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14301

From qamai at openjdk.org  Fri Oct 27 10:26:43 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 27 Oct 2023 10:26:43 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: 
References: 
 
 <6Ywn5vjecuN2UtqWT6IdM_EyK4xP4foammAeoJCvxx8=.2ab7ba6f-fb37-4620-96b1-9e39b4e939e4@github.com>
 
Message-ID: 

On Fri, 27 Oct 2023 03:49:17 GMT, Yasumasa Suenaga  wrote:

>> src/hotspot/cpu/x86/downcallLinker_x86_64.cpp line 110:
>> 
>>> 108:   __ mov(rsp, r12); // restore sp
>>> 109:   __ reinit_heapbase();
>>> 110: }
>> 
>> This is a minor cleanup to share this code for the three use sites below.
>
> Question: `r12` does not need to remember?
> 
> According to [CallingSequences in OpenJDK Wiki](https://wiki.openjdk.org/display/HotSpot/CallingSequences), `r12` may be reserved for HeapBase if COOP is enabled.  
> (`r12` is also used in another places in downcallLinker_x86_64.cpp without restoring...)

@YaSuenag `r12` is restored in `reinit_heapbase()` if needed and no, `r12` does not need remembering because it is a constant and can be restored from somewhere else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1374370475

From duke at openjdk.org  Fri Oct 27 10:28:38 2023
From: duke at openjdk.org (null)
Date: Fri, 27 Oct 2023 10:28:38 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 22 Jul 2023 04:44:21 GMT, Stuart Marks  wrote:

>> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734 and https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8311905
>
> Hi, thanks for the background and the discussion of the alternatives. I'm not sure that drafting the CSR is the right next step; there are a number of foibles about editing the specifications that come into play when preparing the CSR. However, what you've written above is a good design discussion about the different alternatives and how they affect the specification and the implementation.
> 
> One thing that we need to consider is compatibility. From an excessively pedantic standpoint, any change in behavior is a potential incompatibility (somebody might be relying on that bug!) but I think that fixing obviously incorrect behavior is reasonable. As much as possible I'd like to make sure that things that worked, at least partially, continue to work.
> 
> With this in mind I'm leaning toward allowing a BitSet to contain bits including the Integer.MAX_VALUE bit, and adjusting various specs accordingly. I think the best way to specify this is to say that length() returns an int in the range [0, 2^31] as an unsigned value. In practice of course this means it can return any Java `int` value in the range [0, MAX_VALUE] and also Integer.MIN_VALUE. A sufficiently careful programmer can use such values correctly, as long as they avoid doing certain things such as comparing against zero. (We might want to have a note in the spec to that effect.)
> 
> It's good that you analyzed the `valueOf` methods. It looks to me like the implementation will store an actual array potentially containing bits beyond the MAX_VALUE bit, and this will affect things like length() and size() and such bits won't be accessible via get() or set(). So, on the one hand, this behavior seems clearly broken and ought to be fixed by limiting the input array along the lines suggested by your three options.
> 
> On the other hand, it seems that from looking at the code, it's possible to create an "over-size" BitSet with valueOf(), and perform bulk bit manipulations on it and other BitSets using methods like and(), or(), and xor(). It also appears possible to read out the bits successfully using toByteArray() or toLongArray(). Thus an application might be able to manipulate bit arrays of up to about 2^37 bits long by using BitSet with long arrays or LongBuffers. Restricting the input of valueOf() to 2^31 bits would break such applications.
> 
> Also note that the specification says the bits are numbered by nonnegative integers (that is, zero to 2^31) which would seem to preclude longer bit arrays. However, if somebody...

Hey @stuart-marks (cc @liach @AlanBateman @ExE-Boss),
I think this discussion has stalled a bit. Would it be an idea to at least push this commit through, so the get(i,j) bug at least is fixed, and then maybe move the larger discussion to a different place? (Eg. a pull request for [JDK-8311905](https://bugs.openjdk.org/browse/JDK-8311905)?)
I don't believe the CSR is _essential_ to fix the get(i,j) issue, and clearly there is some disagreement on what the right solution is.
If we do end up changing the spec for the BitSet, there will almost certainly be larger changes in the class than just the get(i,j) method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1782673878

From alanb at openjdk.org  Fri Oct 27 10:34:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Oct 2023 10:34:44 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 22 Jul 2023 04:44:21 GMT, Stuart Marks  wrote:

>> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734 and https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8311905
>
> Hi, thanks for the background and the discussion of the alternatives. I'm not sure that drafting the CSR is the right next step; there are a number of foibles about editing the specifications that come into play when preparing the CSR. However, what you've written above is a good design discussion about the different alternatives and how they affect the specification and the implementation.
> 
> One thing that we need to consider is compatibility. From an excessively pedantic standpoint, any change in behavior is a potential incompatibility (somebody might be relying on that bug!) but I think that fixing obviously incorrect behavior is reasonable. As much as possible I'd like to make sure that things that worked, at least partially, continue to work.
> 
> With this in mind I'm leaning toward allowing a BitSet to contain bits including the Integer.MAX_VALUE bit, and adjusting various specs accordingly. I think the best way to specify this is to say that length() returns an int in the range [0, 2^31] as an unsigned value. In practice of course this means it can return any Java `int` value in the range [0, MAX_VALUE] and also Integer.MIN_VALUE. A sufficiently careful programmer can use such values correctly, as long as they avoid doing certain things such as comparing against zero. (We might want to have a note in the spec to that effect.)
> 
> It's good that you analyzed the `valueOf` methods. It looks to me like the implementation will store an actual array potentially containing bits beyond the MAX_VALUE bit, and this will affect things like length() and size() and such bits won't be accessible via get() or set(). So, on the one hand, this behavior seems clearly broken and ought to be fixed by limiting the input array along the lines suggested by your three options.
> 
> On the other hand, it seems that from looking at the code, it's possible to create an "over-size" BitSet with valueOf(), and perform bulk bit manipulations on it and other BitSets using methods like and(), or(), and xor(). It also appears possible to read out the bits successfully using toByteArray() or toLongArray(). Thus an application might be able to manipulate bit arrays of up to about 2^37 bits long by using BitSet with long arrays or LongBuffers. Restricting the input of valueOf() to 2^31 bits would break such applications.
> 
> Also note that the specification says the bits are numbered by nonnegative integers (that is, zero to 2^31) which would seem to preclude longer bit arrays. However, if somebody...

> Hey @stuart-marks (cc @liach @AlanBateman @ExE-Boss), I think this discussion has stalled a bit. Would it be an idea to at least push this commit through.

No, as I don't think there is agreement yet on this direction. Also all of the options involve a spec change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1782681710

From mdoerr at openjdk.org  Fri Oct 27 11:31:40 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 27 Oct 2023 11:31:40 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: 
References: 
 
 <6Ywn5vjecuN2UtqWT6IdM_EyK4xP4foammAeoJCvxx8=.2ab7ba6f-fb37-4620-96b1-9e39b4e939e4@github.com>
 
 
Message-ID: 

On Fri, 27 Oct 2023 10:23:43 GMT, Quan Anh Mai  wrote:

>> Question: `r12` does not need to remember?
>> 
>> According to [CallingSequences in OpenJDK Wiki](https://wiki.openjdk.org/display/HotSpot/CallingSequences), `r12` may be reserved for HeapBase if COOP is enabled.  
>> (`r12` is also used in another places in downcallLinker_x86_64.cpp without restoring...)
>
> @YaSuenag `r12` is restored in `reinit_heapbase()` if needed and no, `r12` does not need remembering because it is a constant and can be restored from somewhere else.

I think your code is fine. Restoring `r12_heapbase` at this point is not bad because `runtime_call` is only for slow paths. I don't think it should be moved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1374436854

From rgiulietti at openjdk.org  Fri Oct 27 12:10:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 27 Oct 2023 12:10:07 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v3]
In-Reply-To: 
References: 
Message-ID: <54uc54dqaE7tut0nQ9_jdWzMjnMdGDGbw0UZNtdzqM8=.50178293-96f5-4115-a7ee-93cbdd3b8e42@github.com>

> By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into 8316662
 - Uppercase JLA.
 - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15861/files
  - new: https://git.openjdk.org/jdk/pull/15861/files/092c2046..87e09f38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15861&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15861&range=01-02

  Stats: 66648 lines in 2489 files changed: 41106 ins; 11953 del; 13589 mod
  Patch: https://git.openjdk.org/jdk/pull/15861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15861/head:pull/15861

PR: https://git.openjdk.org/jdk/pull/15861

From duke at openjdk.org  Fri Oct 27 13:29:37 2023
From: duke at openjdk.org (null)
Date: Fri, 27 Oct 2023 13:29:37 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v9]
In-Reply-To: 
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
 <8wFp2rFtTWDGTQ4AKB4QYNjb0eJrg6aDznXP3p8agKE=.a0b699ac-f725-4bfd-9d07-bc7ace20b0a0@github.com>
 
 <4gJ8559jIkiqFQNZHixQ1omfMjW7kKRtjaYFc92Xb90=.b64864d7-a56e-40bd-9581-d5abf97cb7e5@github.com>
 
Message-ID: <5SwozIlMyFDx9yzlGOWnjNgYp2Jciix5B3ViuA68fjY=.1f7e374f-8321-4641-a566-59c4bd378274@github.com>

On Wed, 20 Sep 2023 16:33:56 GMT, Paul Sandoz  wrote:

>>> > Alan, you mentioned that DualPivotQuicksort will need detailed review. Can we go ahead and start reviewing? Laurent checked performance, JMH results look fine.
>>> 
>>> As before, I think the main question with this change is whether adding radix sort to the mix is worth the complexity and additional code to maintain. Also as we discussed in the previous PR, the additional memory needed for the radix sort may have an effect on other things that are going on concurrently. I know it has been updated to handle OOME but I think potential reviewers would need to be comfortable with that part.
>> 
>> I too share concerns about the potential increased use of memory for sorting ints/longs/floats/doubles. With modern SIMD hardware and data parallel techniques we can apply quicksort much more efficiently. I think it is important to determine to what extent this reduces the need for radix sort. To determine that we would need to carefully measure against the AVX-512 implementation (with ongoing improvements) with appropriately initialized data to sort, and further measure against an AVX2 version.
>
>> Hi Paul (@PaulSandoz), Alan (@AlanBateman), Any update? Do you agree with Radix sort in parallel case only?
> 
> I think its definitely a better fit, but another aspect of my previous comment was wondering if we need a radix sort if the vectorized quicksort implementation is fast enough. IMO we need to compare performance results with the vectorized quick sort, and be aware of future enhancements to that.

Hello @PaulSandoz and @AlanBateman !

Did you have time to look at the latest benchmarking?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1782915551

From viktor.klang at oracle.com  Fri Oct 27 13:50:18 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 27 Oct 2023 13:50:18 +0000
Subject: Update on JEP-461: Stream Gatherers (Preview)
Message-ID: 

Greetings,

As you may have already seen, Stream Gatherers is now a Preview JEP with Candidate status

Work-in-progress (interfaces, implementation, tests, benches, and documentation) for JEP-461 is currently available here.

While the design has held up well, there are some important improvements made since the original design document was written.

Notable changes (without any particular order):

  *   Stream::gather() now has a default implementation.

  *   Gatherer::supplier() was renamed to Gatherer::initializer() to better reflect intent.

  *   Gatherer.Sink was renamed to Gatherer.Downstream to better signal what it represents.

  *   Gatherer::collect(Collector) and its companion type Gatherer.ThenCollector was dropped due to compatibility concerns with existing code which operates on Collector.

  *
Gatherer.Characteristics have been eliminated and superseded by having default values that are used as sentinels.
 (discussed further down the list)
This is important because with the Characteristics-model keeping alignment between Characteristics and actual implementation proved brittle, and under composition of Gatherers computing the union was inefficient and mostly lead to an empty set in the end.

  *   Gatherer.defaultInitializer(), Gatherer.defaultCombiner(), and Gatherer.defaultFinisher() were added as static methods?these are the sentinels used to elide calling the initializer, to elide calling the combiner (avoid parallelization), and to elide calling the finisher, respectively.

  *   Gatherer::initializer(), Gatherer::combiner(), and Gatherer::finisher() default implementations return the respective sentinels.

  *   A subtype of Integrator named Greedy was added, together with a factory method to guide lambda-to-nominal-type conversion. This allows creators of Gatherers to signal that an Integrator will never initiate a short-circuit (but may relay one from downstream), and that is available during evaluation to determine if the operation can short-circuit or not.

  *   Factories for creating anonymous Gatherers were expanded upon to include Gatherer.of() and Gatherer.ofSequential() with different sets of parameters, primarily to make it more ergonomical and easier to read and write the code using those factories.

  *   A curated set of initial built-in Gatherers is located in java.util.stream.Gatherers

I recently presented Gatherers at Devoxx, which I'd recommend watching for an introduction to the feature.
[cid:d048f613-b144-4ff9-a2d3-98e0765aab57]
Teaching old Streams new tricks By Viktor Klang
Have you ever wanted to perform an operation on a java.util.stream.Stream only to find that the existing set of operations didn't provide what you needed?forcing you to break out early from the Stream and perform the logic outside of it? As a matter of fact, java.util.stream was the first JDK API designed with lambdas in mind and was ...
www.youtube.com
??????

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-cztoycvq.jpg
Type: image/jpeg
Size: 26656 bytes
Desc: Outlook-cztoycvq.jpg
URL: 

From alanb at openjdk.org  Fri Oct 27 14:00:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Oct 2023 14:00:34 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
Message-ID: 

On Thu, 26 Oct 2023 21:08:07 GMT, Calvin Cheung  wrote:

> I've pushed another update with the following changes:
> 
> * in the VM code, skip archiving full module graph if there's an incubator module by checking if the ArchivedBootLayer::archivedBootLayer is available;

I think we still have the issue when the archive is created with a main module (meaning a named module) but you run with the class path as the initial module, e.g. java -version. Is the update missing the changes to ArchivedModuleGraph as I think that will need to check that the main module matches the archive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1374624923

From ysuenaga at openjdk.org  Fri Oct 27 14:41:46 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 27 Oct 2023 14:41:46 GMT
Subject: RFR: 8254693: Add Panama feature to pass heap segments to native
 code [v12]
In-Reply-To: 
References: 
 
 <6Ywn5vjecuN2UtqWT6IdM_EyK4xP4foammAeoJCvxx8=.2ab7ba6f-fb37-4620-96b1-9e39b4e939e4@github.com>
 
 
 
Message-ID: 

On Fri, 27 Oct 2023 11:28:29 GMT, Martin Doerr  wrote:

>> @YaSuenag `r12` is restored in `reinit_heapbase()` if needed and no, `r12` does not need remembering because it is a constant and can be restored from somewhere else.
>
> I think your code is fine. Restoring `r12_heapbase` at this point is not bad because `runtime_call` is only for slow paths. I don't think it should be moved.

Thanks everyone! I understood `r12` is restored in `reinit_heapbase()`. It is necessary. I have no comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1374678254

From jvernee at openjdk.org  Fri Oct 27 14:53:49 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 27 Oct 2023 14:53:49 GMT
Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure
 [v5]
In-Reply-To: 
References: 
Message-ID: <0gwzua-gUHJZukl44J79u_k4GRw_KUfrZuS3qc5SG14=.56caf591-f209-4bb6-a035-0552905ad5dd@github.com>

> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  add nullptr checks to other platforms

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16311/files
  - new: https://git.openjdk.org/jdk/pull/16311/files/52e875eb..a75d072d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=03-04

  Stats: 51 lines in 8 files changed: 51 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16311/head:pull/16311

PR: https://git.openjdk.org/jdk/pull/16311

From lmesnik at openjdk.org  Fri Oct 27 16:19:30 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 27 Oct 2023 16:19:30 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: 
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
 
 
 
Message-ID: 

On Fri, 27 Oct 2023 05:55:43 GMT, David Holmes  wrote:

>> It is still used in tests and we should ignore it like jtreg doing.
>
> Shouldn't this code first retrieve the current default exception handler, and then check whether t is a virtual thread, and if so handle the exception as appropriate (not sure System.exit is appropriate ..). Then for non-virtual threads it delegates to the previous default handler.
> 
> final UncaughtExceptionHandler originalUEH = Thread.getDefaultUncaughtExceptionHandler();
> Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
>         if (t.isVirtual()) {
>             // ...
>         } else {
>             originalUEH.uncaughtException(t, e);
>         }
> });

There shouldn't be an original UHE. jtreg doesn't set it. The goal is to add this handler for all threads, not only virtual. 
Please note, that it is planned to add it only until the similar problem in jtreg is completely fixed. 
I thought to add something like 

Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
  UHE.ecxeptionThrown = e;
}

...

 @Override
    public Thread newThread(Runnable task) {
        return VIRTUAL_TF.newThread(new Runnable() -> {
                task.run();
                if (UHE.ecxeptionThrown != null) {
                         throw new RuntimeException(UHE.ecxeptionThrown);
                }
            );
    }
}


So test actually throws exceptions. It might miss exceptions for threads that finish later than the main thread. but might it is ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16369#discussion_r1374790707

From ccheung at openjdk.org  Fri Oct 27 16:25:32 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 27 Oct 2023 16:25:32 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
Message-ID: <5lYwJpqhgq2MEJ17xpslna437GsmZFAH5v3FyWRhh-Q=.83077177-f238-4cdb-b65d-06e013b4edaf@github.com>

On Fri, 27 Oct 2023 13:57:38 GMT, Alan Bateman  wrote:

>> I've pushed another update with the following changes:
>> 
>> - in the VM code, skip archiving full module graph if there's an incubator module by checking if the ArchivedBootLayer::archivedBootLayer is available;
>> - included your suggested code changes in ModuleBootstrap.java;
>> - added a test scenario with an incubator module.
>
>> I've pushed another update with the following changes:
>> 
>> * in the VM code, skip archiving full module graph if there's an incubator module by checking if the ArchivedBootLayer::archivedBootLayer is available;
> 
> I think we still have the issue when the archive is created with a main module (meaning a named module) but you run with the class path as the initial module, e.g. java -version. Is the update missing the changes to ArchivedModuleGraph as I think that will need to check that the main module matches the archive.

I reran the script you sent me few days ago and got the expected results with the latest changes.
The checking of the main module name matches between dump time and runtime is performed in the VM code. If an archive (even the default CDS archive classes.jsa) is created with the -m option, running with just `java -version` will disable the optimized module handling.

[0.136s][info ][cds        ] _archived_main_module_name m
[0.136s][info ][cds        ] Module m specified during dump time but not during runtime
[0.136s][info ][cds        ] Disabling optimized module handling
[0.136s][info ][cds        ] optimized module handling: disabled
[0.136s][info ][cds        ] full module graph: disabled

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1374796890

From iklam at openjdk.org  Fri Oct 27 16:36:37 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 27 Oct 2023 16:36:37 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v6]
In-Reply-To: 
References: 
 
Message-ID: <_kRxr4CnDC2ouiocb43oqSNVPOI1xeJ4LTRhXwWeeYg=.eef409db-3a40-483d-9e54-9914bb524520@github.com>

On Thu, 26 Oct 2023 21:24:46 GMT, Calvin Cheung  wrote:

>> Please review this changeset for adding support for `--module` (-m) option for CDS.
>> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
>> 
>> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge master
>  - skip archiving full module graph is there is an incubator module
>  - fix typo
>  - simplify some code in modules.cpp
>  - comments from Alan and Ioi; add missing @run tag in the test
>  - Merge branch 'master' into improve-CDS-module-graph
>  - better way to check if a module is a JDK module
>  - initial review comments from Ioi
>  - 8316969: Improve CDS module graph support for --module option

The new version looks really good now. I found one merge error and have a suggestion for adding one more test.

src/hotspot/share/cds/metaspaceShared.cpp line 790:

> 788:   ArchiveHeapWriter::init();
> 789:   if (use_full_module_graph()) {
> 790:     HeapShared::reset_archived_object_states(CHECK);

This block of code needs to be inside `if (CDSConfig::is_dumping_heap())`

test/hotspot/jtreg/runtime/cds/appcds/jigsaw/module/ModuleOption.java line 107:

> 105:         oa.shouldHaveExitValue(0)
> 106:           // module graph won't be archived with an incubator module
> 107:           .shouldContain("archivedBootLayer not available, disabling full module graph");

For thoroughness, I think we should also check for this log in heapShared.cpp:


    if (record->is_full_module_graph() && !CDSConfig::is_loading_full_module_graph()) {
      if (log_is_enabled(Info, cds, heap)) {
        ResourceMark rm(THREAD);
        log_info(cds, heap)("subgraph %s cannot be used because full module graph is disabled",
                            k->external_name());
      }
      return nullptr;
    }

-------------

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16016#pullrequestreview-1702150002
PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1374801536
PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1374805801

From jlu at openjdk.org  Fri Oct 27 17:31:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Oct 2023 17:31:43 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method [v3]
In-Reply-To: 
References: 
Message-ID: <-oqg7gWebD3KgZJj67_mukYJ_71WY7S2ZE5KBZWXBoI=.3d56d213-c6d0-4740-8703-3c1c0509c83f@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 
> 
> That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - additional cleanup/wording changes
 - replace spec fix with private methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16064/files
  - new: https://git.openjdk.org/jdk/pull/16064/files/dc9cbae6..74847121

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16064&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16064&range=01-02

  Stats: 64 lines in 2 files changed: 35 ins; 13 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16064/head:pull/16064

PR: https://git.openjdk.org/jdk/pull/16064

From alanb at openjdk.org  Fri Oct 27 17:42:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Oct 2023 17:42:33 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: <5lYwJpqhgq2MEJ17xpslna437GsmZFAH5v3FyWRhh-Q=.83077177-f238-4cdb-b65d-06e013b4edaf@github.com>
References: 
 
 
 
 
 
 
 
 
 <5lYwJpqhgq2MEJ17xpslna437GsmZFAH5v3FyWRhh-Q=.83077177-f238-4cdb-b65d-06e013b4edaf@github.com>
Message-ID: 

On Fri, 27 Oct 2023 16:23:04 GMT, Calvin Cheung  wrote:

> I reran the script you sent me few days ago and got the expected results with the latest changes. The checking of the main module name matches between dump time and runtime is performed in the VM code. If an archive (even the default CDS archive classes.jsa) is created with the -m option, running with just `java -version` will disable the optimized module handling.
> 
> ```
> [0.136s][info ][cds        ] _archived_main_module_name m
> [0.136s][info ][cds        ] Module m specified during dump time but not during runtime
> [0.136s][info ][cds        ] Disabling optimized module handling
> [0.136s][info ][cds        ] optimized module handling: disabled
> [0.136s][info ][cds        ] full module graph: disabled
> ```

Can you check that ArchivedModuleGraph.archivedModuleGraph is null when disabled? When I tried it, it wasn't null so ModuleBootstrap has a module graph containing the modules for m.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1374875540

From naoto at openjdk.org  Fri Oct 27 18:04:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Oct 2023 18:04:33 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method [v3]
In-Reply-To: <-oqg7gWebD3KgZJj67_mukYJ_71WY7S2ZE5KBZWXBoI=.3d56d213-c6d0-4740-8703-3c1c0509c83f@github.com>
References: 
 <-oqg7gWebD3KgZJj67_mukYJ_71WY7S2ZE5KBZWXBoI=.3d56d213-c6d0-4740-8703-3c1c0509c83f@github.com>
Message-ID: <6VdB_bdBBUJqBHKnpfO5uyRWODjhJHFDcKWCXl281Bw=.a7ecdeb8-6a06-4c66-8d2f-4a8110cccd02@github.com>

On Fri, 27 Oct 2023 17:31:43 GMT, Justin Lu  wrote:

>> Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors.
>> 
>> The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - additional cleanup/wording changes
>  - replace spec fix with private methods

src/java.base/share/classes/java/text/ChoiceFormat.java line 560:

> 558:      * @see #previousDouble
> 559:      */
> 560:     public static double nextDouble (double d) {

Is removing `final` OK here? Wouldn't this allow defining the static method in the subclass?

src/java.base/share/classes/java/text/ChoiceFormat.java line 575:

> 573:      * @see #nextDouble
> 574:      */
> 575:     public static double previousDouble (double d) {

same here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16064#discussion_r1374892774
PR Review Comment: https://git.openjdk.org/jdk/pull/16064#discussion_r1374892964

From joehw at openjdk.org  Fri Oct 27 18:16:05 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 27 Oct 2023 18:16:05 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v4]
In-Reply-To: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
Message-ID: 

> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.

Joe Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8316996
   Merge before update
 - add a test for the NPE case
 - addressing review comments, plus use URL for relative URI
 - 8316996: Catalog API Enhancement: add a factory method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16045/files
  - new: https://git.openjdk.org/jdk/pull/16045/files/f1d726ec..a0b5d4a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=02-03

  Stats: 46092 lines in 1883 files changed: 27518 ins; 9505 del; 9069 mod
  Patch: https://git.openjdk.org/jdk/pull/16045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16045/head:pull/16045

PR: https://git.openjdk.org/jdk/pull/16045

From jlu at openjdk.org  Fri Oct 27 18:40:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Oct 2023 18:40:56 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors.
> 
> The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  re-apply 'final' to the static methods in ChoiceFormat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16064/files
  - new: https://git.openjdk.org/jdk/pull/16064/files/74847121..a44ea641

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16064&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16064&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16064/head:pull/16064

PR: https://git.openjdk.org/jdk/pull/16064

From jlu at openjdk.org  Fri Oct 27 18:40:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Oct 2023 18:40:59 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method [v3]
In-Reply-To: <6VdB_bdBBUJqBHKnpfO5uyRWODjhJHFDcKWCXl281Bw=.a7ecdeb8-6a06-4c66-8d2f-4a8110cccd02@github.com>
References: 
 <-oqg7gWebD3KgZJj67_mukYJ_71WY7S2ZE5KBZWXBoI=.3d56d213-c6d0-4740-8703-3c1c0509c83f@github.com>
 <6VdB_bdBBUJqBHKnpfO5uyRWODjhJHFDcKWCXl281Bw=.a7ecdeb8-6a06-4c66-8d2f-4a8110cccd02@github.com>
Message-ID: 

On Fri, 27 Oct 2023 18:00:38 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - additional cleanup/wording changes
>>  - replace spec fix with private methods
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 560:
> 
>> 558:      * @see #previousDouble
>> 559:      */
>> 560:     public static double nextDouble (double d) {
> 
> Is removing `final` OK here? Wouldn't this allow defining the static method in the subclass?

Right, we don't want those methods to now have the ability to be hidden. Got carried away with the IDE suggested tips. Reverted here and in the other occurrence, thanks for correcting.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16064#discussion_r1374928055

From naoto at openjdk.org  Fri Oct 27 18:55:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Oct 2023 18:55:34 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 27 Oct 2023 18:40:56 GMT, Justin Lu  wrote:

>> Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors.
>> 
>> The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-apply 'final' to the static methods in ChoiceFormat

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16064#pullrequestreview-1702372815

From ccheung at openjdk.org  Fri Oct 27 19:06:34 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 27 Oct 2023 19:06:34 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 <5lYwJpqhgq2MEJ17xpslna437GsmZFAH5v3FyWRhh-Q=.83077177-f238-4cdb-b65d-06e013b4edaf@github.com>
 
Message-ID: <6Uy4_u0RQeGKXwUYk8REFcRYlx1AuSgbyQSClrlwFLU=.8c21fcdb-89b4-4bfc-a812-e0bed27d0efe@github.com>

On Fri, 27 Oct 2023 17:40:12 GMT, Alan Bateman  wrote:

>> I reran the script you sent me few days ago and got the expected results with the latest changes.
>> The checking of the main module name matches between dump time and runtime is performed in the VM code. If an archive (even the default CDS archive classes.jsa) is created with the -m option, running with just `java -version` will disable the optimized module handling.
>> 
>> [0.136s][info ][cds        ] _archived_main_module_name m
>> [0.136s][info ][cds        ] Module m specified during dump time but not during runtime
>> [0.136s][info ][cds        ] Disabling optimized module handling
>> [0.136s][info ][cds        ] optimized module handling: disabled
>> [0.136s][info ][cds        ] full module graph: disabled
>
>> I reran the script you sent me few days ago and got the expected results with the latest changes. The checking of the main module name matches between dump time and runtime is performed in the VM code. If an archive (even the default CDS archive classes.jsa) is created with the -m option, running with just `java -version` will disable the optimized module handling.
>> 
>> ```
>> [0.136s][info ][cds        ] _archived_main_module_name m
>> [0.136s][info ][cds        ] Module m specified during dump time but not during runtime
>> [0.136s][info ][cds        ] Disabling optimized module handling
>> [0.136s][info ][cds        ] optimized module handling: disabled
>> [0.136s][info ][cds        ] full module graph: disabled
>> ```
> 
> Can you check that ArchivedModuleGraph.archivedModuleGraph is null when disabled? When I tried it, it wasn't null so ModuleBootstrap has a module graph containing the modules for m.

The `ArchivedModuleGraph.java` wasn't changed. So if `-m` is not specified, the `archivedModuleGraph` is non-null; if `-m` is specified, the `archivedModuleGraph` is null.
So running `java -version`, the archivedModuleGraph is non-null, but the module m won't be loaded from the archive. I'm seeing the following log output:

`[0.220s][debug][module     ] define_module(): creation of module: m, version: null, location: jrt:/m, loader data: 0x00007f201819dd60 for instance a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x000000011f010500}, package #: 1`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1374951369

From lancea at openjdk.org  Fri Oct 27 19:11:32 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 27 Oct 2023 19:11:32 GMT
Subject: RFR: JDK-8317612: ChoiceFormat and MessageFormat constructors call
 non-final public method [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 27 Oct 2023 18:40:56 GMT, Justin Lu  wrote:

>> Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors.
>> 
>> The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-apply 'final' to the static methods in ChoiceFormat

Looks reasonable.  I assume you validated the links work in the generated docs as a sanity check

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16064#pullrequestreview-1702392861

From joehw at openjdk.org  Fri Oct 27 19:20:01 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 27 Oct 2023 19:20:01 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v5]
In-Reply-To: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
Message-ID: 

> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Impl CSR Changes: change the parameter type from String to Enum

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16045/files
  - new: https://git.openjdk.org/jdk/pull/16045/files/a0b5d4a8..89b6b7ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=03-04

  Stats: 168 lines in 7 files changed: 72 ins; 46 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/16045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16045/head:pull/16045

PR: https://git.openjdk.org/jdk/pull/16045

From lancea at openjdk.org  Fri Oct 27 19:20:02 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 27 Oct 2023 19:20:02 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v5]
In-Reply-To: 
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
 
Message-ID: 

On Fri, 27 Oct 2023 19:16:33 GMT, Joe Wang  wrote:

>> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Impl CSR Changes: change the parameter type from String to Enum

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16045#pullrequestreview-1702399673

From naoto at openjdk.org  Fri Oct 27 20:44:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Oct 2023 20:44:32 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v5]
In-Reply-To: 
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
 
Message-ID: 

On Fri, 27 Oct 2023 19:20:01 GMT, Joe Wang  wrote:

>> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Impl CSR Changes: change the parameter type from String to Enum

LGTM

src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java line 283:

> 281:                     return type;
> 282:                 }
> 283:             }

Instead of looping through all the elements, `Enum.valueOf()` can be used (and it appropriately throws IAE if not found).

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16045#pullrequestreview-1702510763
PR Review Comment: https://git.openjdk.org/jdk/pull/16045#discussion_r1375025707

From joehw at openjdk.org  Fri Oct 27 22:15:49 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 27 Oct 2023 22:15:49 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v6]
In-Reply-To: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
Message-ID: 

> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  add IAE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16045/files
  - new: https://git.openjdk.org/jdk/pull/16045/files/89b6b7ea..f7095aa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16045&range=04-05

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16045/head:pull/16045

PR: https://git.openjdk.org/jdk/pull/16045

From joehw at openjdk.org  Fri Oct 27 22:26:32 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 27 Oct 2023 22:26:32 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v5]
In-Reply-To: 
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
 
 
Message-ID: 

On Fri, 27 Oct 2023 20:41:59 GMT, Naoto Sato  wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Impl CSR Changes: change the parameter type from String to Enum
>
> src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java line 283:
> 
>> 281:                     return type;
>> 282:                 }
>> 283:             }
> 
> Instead of looping through all the elements, `Enum.valueOf()` can be used (and it appropriately throws IAE if not found).

Thanks. Added IAE. Enum.valueOf() is nice. However, in this case, the Enum type is mapped to the resolve property that was defined to be case sensitive. It would therefore require validating the case and then convert it to upper case before calling valueOf. While the current impl requires loop, it uses toString() that's mapped to the resolve property.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16045#discussion_r1375090816

From naoto at openjdk.org  Fri Oct 27 22:37:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Oct 2023 22:37:32 GMT
Subject: RFR: 8316996: Catalog API Enhancement: add a factory method [v5]
In-Reply-To: 
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
 
 
 
Message-ID: <1hBaEIZ1HpWlHtAEkNskxVrauYU3Q_7XvhWpR7Ov7Kk=.79078741-c4e2-482b-bf0f-2839f1991b8f@github.com>

On Fri, 27 Oct 2023 22:21:41 GMT, Joe Wang  wrote:

>> src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java line 283:
>> 
>>> 281:                     return type;
>>> 282:                 }
>>> 283:             }
>> 
>> Instead of looping through all the elements, `Enum.valueOf()` can be used (and it appropriately throws IAE if not found).
>
> Thanks. Added IAE. Enum.valueOf() is nice. However, in this case, the Enum type is mapped to the resolve property that was defined to be case sensitive. It would therefore require validating the case and then convert it to upper case before calling valueOf. While the current impl requires loop, it uses toString() that's mapped to the resolve property.

That is correct. Thanks for checking

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16045#discussion_r1375099347

From joehw at openjdk.org  Sat Oct 28 03:41:42 2023
From: joehw at openjdk.org (Joe Wang)
Date: Sat, 28 Oct 2023 03:41:42 GMT
Subject: Integrated: 8316996: Catalog API Enhancement: add a factory method
In-Reply-To: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
References: <5W9SYNs6wTvDW-XINwi8vdM8KjIXbLhzsAOxw8X-p68=.cda8fe10-e259-4b46-8780-b6b156fa9a4f@github.com>
Message-ID: 

On Wed, 4 Oct 2023 22:56:28 GMT, Joe Wang  wrote:

> Add a new factory method so that a CatalogResolver can be created with a resolve property on top of the Catalog object.

This pull request has now been integrated.

Changeset: 96bec358
Author:    Joe Wang 
URL:       https://git.openjdk.org/jdk/commit/96bec3584ced3ea1e75cc40bb402f571aba78b09
Stats:     325 lines in 9 files changed: 277 ins; 32 del; 16 mod

8316996: Catalog API Enhancement: add a factory method

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/16045

From alanb at openjdk.org  Sat Oct 28 06:39:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 28 Oct 2023 06:39:35 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: <6Uy4_u0RQeGKXwUYk8REFcRYlx1AuSgbyQSClrlwFLU=.8c21fcdb-89b4-4bfc-a812-e0bed27d0efe@github.com>
References: 
 
 
 
 
 
 
 
 
 <5lYwJpqhgq2MEJ17xpslna437GsmZFAH5v3FyWRhh-Q=.83077177-f238-4cdb-b65d-06e013b4edaf@github.com>
 
 <6Uy4_u0RQeGKXwUYk8REFcRYlx1AuSgbyQSClrlwFLU=.8c21fcdb-89b4-4bfc-a812-e0bed27d0efe@github.com>
Message-ID: 

On Fri, 27 Oct 2023 19:03:36 GMT, Calvin Cheung  wrote:

> The `ArchivedModuleGraph.java` wasn't changed. So if `-m` is not specified, the `archivedModuleGraph` is non-null; if `-m` is specified, the `archivedModuleGraph` is null. So running `java -version`, the archivedModuleGraph is non-null, but the module m won't be loaded from the archive.

Right, but ArchivedModuleGraph provides the initial value for hasIncubatorModules, hasSplitPackages, ... This is why `java -version` confusingly prints a warning that an incubator module has been resolved. We've had archiving of the module graph (configuration) for a long time but it's only been for the case where the initial module is the unnamed module. I think archiving of the boot layer for the case where the initial module is a named module means we have to re-visit ArchivedModuleGraph. I think ArchivedModuleGraph.get has to return null when the archive doesn't match the mainModule. Part of it wonder if we should remove ArchivedModuleGraph, support archiving of the boot layer only.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1375183933

From duke at openjdk.org  Sat Oct 28 17:08:07 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 28 Oct 2023 17:08:07 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v3]
In-Reply-To: 
References: 
Message-ID: 

> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
> 
> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
> 
> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
> 
> 
> When extracting, if the zip64 extended information extra 
> field is present for the file the compressed and 
> uncompressed sizes will be 8 byte values.
> 
> 
> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
> 
> `echo hello | zip -fd > hello.zip`
> 
> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.

Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:

 - Remove excessive comment
 - Move isZip64ExtBlockSizeValid to ZipUtils, use it from ZipInputStream and ZipFile.Source
 - Merge branch 'master' into data-descriptor
 - Use block comments instead of javadoc comments to avoid doclint warnings
 - Merge branch 'master' into data-descriptor
 - Zip64 extra field of a LOC header has 1-3 long components
 - Clarify comment for shouldIgnoreExcessiveExtraSize
 - Update test to use a Zip64 file produced using the zip command with the -fd flag
 - Add comment to explaining the setExtraSize and readZipInputStream methods and the zip64File field.
 - Add comment to the call site of hasZip64 extra
 - ... and 11 more: https://git.openjdk.org/jdk/compare/ac50234c...fad0da2e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12524/files
  - new: https://git.openjdk.org/jdk/pull/12524/files/01216ef7..fad0da2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=01-02

  Stats: 1001872 lines in 12942 files changed: 671014 ins; 209199 del; 121659 mod
  Patch: https://git.openjdk.org/jdk/pull/12524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12524/head:pull/12524

PR: https://git.openjdk.org/jdk/pull/12524

From duke at openjdk.org  Sat Oct 28 17:14:43 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 28 Oct 2023 17:14:43 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v3]
In-Reply-To: 
References: 
 
Message-ID: <5X4hPE3Dq0PzPXtpr6i6Ck5RkwauMa4ksPbuTlxi2HQ=.99a209b0-ad60-4730-b9c1-4ca5815e4c84@github.com>

On Sat, 28 Oct 2023 17:08:07 GMT, Eirik Bjorsnos  wrote:

>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
>> 
>> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
>> 
>> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
>> 
>> 
>> When extracting, if the zip64 extended information extra 
>> field is present for the file the compressed and 
>> uncompressed sizes will be 8 byte values.
>> 
>> 
>> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
>> 
>> `echo hello | zip -fd > hello.zip`
>> 
>> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Remove excessive comment
>  - Move isZip64ExtBlockSizeValid to ZipUtils, use it from ZipInputStream and ZipFile.Source
>  - Merge branch 'master' into data-descriptor
>  - Use block comments instead of javadoc comments to avoid doclint warnings
>  - Merge branch 'master' into data-descriptor
>  - Zip64 extra field of a LOC header has 1-3 long components
>  - Clarify comment for shouldIgnoreExcessiveExtraSize
>  - Update test to use a Zip64 file produced using the zip command with the -fd flag
>  - Add comment to explaining the setExtraSize and readZipInputStream methods and the zip64File field.
>  - Add comment to the call site of hasZip64 extra
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/473ada95...fad0da2e

Resuscitating this PR since the issue does seem to be causing real problems (see Tomcat Migration tooling discussion in the comments).

Updates:

- `ZipFile` now has `checkZip64ExtraFieldValues`. This method can be reused by `ZipInputStream` when checking the ZIP64 field lengths. To enable reuse, the method is moved to `ZipUtils` and made package protected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1783873510

From lancea at openjdk.org  Sat Oct 28 17:19:42 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 28 Oct 2023 17:19:42 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 28 Oct 2023 17:08:07 GMT, Eirik Bjorsnos  wrote:

>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
>> 
>> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
>> 
>> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
>> 
>> 
>> When extracting, if the zip64 extended information extra 
>> field is present for the file the compressed and 
>> uncompressed sizes will be 8 byte values.
>> 
>> 
>> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
>> 
>> `echo hello | zip -fd > hello.zip`
>> 
>> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Remove excessive comment
>  - Move isZip64ExtBlockSizeValid to ZipUtils, use it from ZipInputStream and ZipFile.Source
>  - Merge branch 'master' into data-descriptor
>  - Use block comments instead of javadoc comments to avoid doclint warnings
>  - Merge branch 'master' into data-descriptor
>  - Zip64 extra field of a LOC header has 1-3 long components
>  - Clarify comment for shouldIgnoreExcessiveExtraSize
>  - Update test to use a Zip64 file produced using the zip command with the -fd flag
>  - Add comment to explaining the setExtraSize and readZipInputStream methods and the zip64File field.
>  - Add comment to the call site of hasZip64 extra
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/b0cd882b...fad0da2e

We need to hold off this PR until https://github.com/openjdk/jdk/pull/15650 has been integrated as it impacts some of the changes proposed here

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1783874658

From duke at openjdk.org  Sat Oct 28 17:37:39 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 28 Oct 2023 17:37:39 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v3]
In-Reply-To: 
References: 
 
Message-ID: <1Qtbbgfnl43in140E7muNTX_Ps8Sd5pWOBLC8lhBAkU=.271f17c7-6719-43d0-bd98-c77bd5d1110c@github.com>

On Sat, 28 Oct 2023 17:08:07 GMT, Eirik Bjorsnos  wrote:

>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
>> 
>> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
>> 
>> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
>> 
>> 
>> When extracting, if the zip64 extended information extra 
>> field is present for the file the compressed and 
>> uncompressed sizes will be 8 byte values.
>> 
>> 
>> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
>> 
>> `echo hello | zip -fd > hello.zip`
>> 
>> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Remove excessive comment
>  - Move isZip64ExtBlockSizeValid to ZipUtils, use it from ZipInputStream and ZipFile.Source
>  - Merge branch 'master' into data-descriptor
>  - Use block comments instead of javadoc comments to avoid doclint warnings
>  - Merge branch 'master' into data-descriptor
>  - Zip64 extra field of a LOC header has 1-3 long components
>  - Clarify comment for shouldIgnoreExcessiveExtraSize
>  - Update test to use a Zip64 file produced using the zip command with the -fd flag
>  - Add comment to explaining the setExtraSize and readZipInputStream methods and the zip64File field.
>  - Add comment to the call site of hasZip64 extra
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/fb1a2716...fad0da2e

> We need to hold off this PR until #15650 has been integrated as it impacts some of the changes proposed here

Thanks Lance, I updated the issue to add [JDK-8314891](https://bugs.openjdk.org/browse/JDK-8314891) as a blocker.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1783879504

From duke at openjdk.org  Sat Oct 28 20:01:56 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 28 Oct 2023 20:01:56 GMT
Subject: RFR: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test [v8]
In-Reply-To: 
References: 
Message-ID: <--iBU8TPNfvfxtOg2suRlEq1wFf55iFZCE_4N9hw9Ww=.52d201f9-89dc-441b-a260-53d5a8f49ef4@github.com>

> Please review this PR which brings  the DataDescriptorSignatureMissing test back to life.
> 
> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` 
> 
> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically.

Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into signature-less-data-descriptor
   
   # Conflicts:
   #	test/jdk/java/util/zip/DataDescriptorSignatureMissing.java
 - The END header LOC offset field and the second entry's CEN LOC offset fields need to be update to account for the four missing signature bytes.
 - Merge branch 'master' into signature-less-data-descriptor
 - Add assertNotNulls to catch unexpectedly missing entries
 - Revert change to Google copyright line, add an Oracle copyright line instead.
 - Use "Signatureless" consistently
 - Remove reference to python in the @summary of DataDescriptorSignatureMissing
 - Update copyright years
 - Add method comments
 - Instead of calling out to python, create a ZIP file and remove the data descriptor signature.

-------------

Changes: https://git.openjdk.org/jdk/pull/12959/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=07
  Stats: 134 lines in 1 file changed: 28 ins; 47 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/12959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12959/head:pull/12959

PR: https://git.openjdk.org/jdk/pull/12959

From duke at openjdk.org  Sat Oct 28 20:06:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Sat, 28 Oct 2023 20:06:37 GMT
Subject: RFR: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test [v8]
In-Reply-To: <--iBU8TPNfvfxtOg2suRlEq1wFf55iFZCE_4N9hw9Ww=.52d201f9-89dc-441b-a260-53d5a8f49ef4@github.com>
References: 
 <--iBU8TPNfvfxtOg2suRlEq1wFf55iFZCE_4N9hw9Ww=.52d201f9-89dc-441b-a260-53d5a8f49ef4@github.com>
Message-ID: <3xrOM6jq1sTYlJJvV0jiuEEVNp5n_WaXmsDyDoqsQ64=.a65ae195-3b51-4209-a057-b024bf77e22e@github.com>

On Sat, 28 Oct 2023 20:01:56 GMT, Eirik Bjorsnos  wrote:

>> Please review this PR which brings  the DataDescriptorSignatureMissing test back to life.
>> 
>> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` 
>> 
>> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into signature-less-data-descriptor
>    
>    # Conflicts:
>    #	test/jdk/java/util/zip/DataDescriptorSignatureMissing.java
>  - The END header LOC offset field and the second entry's CEN LOC offset fields need to be update to account for the four missing signature bytes.
>  - Merge branch 'master' into signature-less-data-descriptor
>  - Add assertNotNulls to catch unexpectedly missing entries
>  - Revert change to Google copyright line, add an Oracle copyright line instead.
>  - Use "Signatureless" consistently
>  - Remove reference to python in the @summary of DataDescriptorSignatureMissing
>  - Update copyright years
>  - Add method comments
>  - Instead of calling out to python, create a ZIP file and remove the data descriptor signature.

Reopening this PR.

Before being closed for inactivity, this PR was reviewed by @jaikiran, who requested that another reviewer with experience in this area also take a look at it before integration.

I think it would be good to have this regression test run automatic again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12959#issuecomment-1783910651

From jpai at openjdk.org  Sun Oct 29 14:13:31 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 29 Oct 2023 14:13:31 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
Message-ID: 

On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik  wrote:

> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 
> 
> A few tests start failing.
> 
> The test
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.
> 
> The test
> java/lang/Thread/virtual/ThreadAPI.java
> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.
> 
> Test 
> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.
> 
> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.

Hello Leonid, in order to understand what exactly we are trying to solve here, I ran a few tests to see how things work without the changes being proposed in this PR. Here's my findings.

A bit of background first. When jtreg runs, either in agent mode or othervm mode, it creates a specific thread within which the actual test code runs. In either of these modes, it uses a custom jtreg specific `ThreadGroup` instance for this thread which is running the test code. This instance of `ThreadGroup` has specific overridden implementation of the `public void uncaughtException(Thread t, Throwable e)` API which keeps track of uncaught exception that might have been thrown by any threads that could have been spawned by the test. After `start()`ing the thread which runs the test code, the jtreg framework then waits for that thread to complete and once completed (either exceptionally or normally), jtreg framework then queries a state on the custom `ThreadGroup` instance to see if any uncaught exception(s) were received during the lifetime of this thread which ran that test. If it finds any, then it marks the test as failed and reports such a failure appropriately in the test repo
 rt. As noted, this applies for both the agent mode and other vm mode. Some important aspects of this implementation is that:

- The custom `ThreadGroup` which has the overridden implementation of the `uncaughtException(Thread t, Throwable e)` method doesn't interfere with the JVM level default exception handler.

- After the thread which ran the test code completes, the decision on whether to fail or pass a test is taken by checking the custom `ThreadGroup`'s state. Once this decision is done, the decision is immediately reported in relevant ways and the test status is marked (i.e. finalized) at this point.

- If this was running in agent vm mode, the agent vm mode continues to operate and isn't terminated and thus is available for subsequent tests. This point I think is important to remember for reasons that will be noted later in this comment.

Now coming to the part where in https://bugs.openjdk.org/browse/JDK-8303703 we introduced a way where jtreg instead of creating a platform thread (backed by its custom implementation of the `ThreadGroup`) to run the test code, now checks the presence of a `ThreadFactory` and if present, lets it create a `Thread` which runs this test code. In the JDK repo, we have an implementation of a `ThreadFactory` which creates a virtual thread instead of platform thread. Instances of virtual threads do belong to a `ThreadGroup`. But that instance of `ThreadGroup` cannot be controlled by user code and thus it cannot have a custom overridden implementation of `uncaughtException(Thread t, Throwable e)`. Any `Thread` created within the test code will have its uncaught exception handled by the virtual thread's `ThreadGroup` whose internal implementation just delegates to the "system" `ThreadGroup` which just writes it out to the `System.err` (of course, I am not considering `Thread`s which have been 
 set with a specific uncaught excepiton handler).

Effectively, what this means is when jtreg runs a test using a platform thread and if that test creates a `Thread` which throws an uncaught exception, then those tests will be marked and reported as failed. If however, jtreg runs a test using a virtual thread, then the same test will now be marked as passed. Clearly this is not a good thing.

For reference, here's the test I used to verify this behaviour:


import java.util.concurrent.atomic.AtomicBoolean;

/*
 * @test
 * @run main FooTest
 */
public class FooTest {
    public static void main(final String[] args) throws Exception {
        final Thread otherThread = new Thread(new AlwaysThrows());
        otherThread.setName("foo-bar");
        System.out.println("Starting " + otherThread.getName() + " thread");
        otherThread.start();
        try {
            otherThread.join(); // wait for it
        } catch (InterruptedException ie) {
            System.out.println(Thread.currentThread().getName() + " was interrupted");
        }
        // verify that the other thread was invoked
        if (!AlwaysThrows.invoked.get()) {
            throw new AssertionError(otherThread.getName() + " wasn't run");
        }
        System.out.println("Test execution done");
    }

    private static class AlwaysThrows implements Runnable {
        private static AtomicBoolean invoked = new AtomicBoolean();

        @Override
        public void run() {
            invoked.set(true);
            System.out.println("Throwing an exception from " + Thread.currentThread().getName());
            throw new RuntimeException("Intentionally thrown exception");
        }
    }

}

Running this with jtreg in agentvm mode

jtreg -report:files -verbose:summary -ea -esa -agentvm -jdk:build/macosx-aarch64/images/jdk test/jdk/java/lang/FooTest.java
....
#section:main
----------messages:(7/204)----------
command: main FooTest
reason: User specified action: run main FooTest 
started: Sun Oct 29 12:40:14 IST 2023
Mode: agentvm
Agent id: 2
finished: Sun Oct 29 12:40:14 IST 2023
elapsed time (seconds): 0.191
...

----------System.out:(4/109)----------
Starting foo-bar thread
Throwing an exception from foo-bar
AgentVMThread was interrupted
Test execution done
----------System.err:(3/35)----------

JavaTest Message: Test complete.

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Intentionally thrown exception


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Intentionally thrown exception


Running in othervm mode:


jtreg -report:files -verbose:summary -ea -esa -othervm -jdk:build/macosx-aarch64/images/jdk test/jdk/java/lang/FooTest.java
...
#section:main
----------messages:(6/192)----------
command: main FooTest
reason: User specified action: run main FooTest 
started: Sun Oct 29 12:41:22 IST 2023
Mode: othervm
finished: Sun Oct 29 12:41:22 IST 2023
elapsed time (seconds): 0.073
----------configuration:(0/0)----------
----------System.out:(2/59)----------
Starting foo-bar thread
Throwing an exception from foo-bar
----------System.err:(4/255)----------
java.lang.RuntimeException: Intentionally thrown exception
	at FooTest$AlwaysThrows.run(FooTest.java:32)
	at java.base/java.lang.Thread.run(Thread.java:1570)
STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Intentionally thrown exception


So in both agentvm and othervm mode it gets marked as failed. Now running the same using the virtual thread feature of jtreg:


jtreg -report:files -verbose:summary -ea -esa -agentvm -jdk:build/macosx-aarch64/images/jdk  -testThreadFactoryPath:.../build/macosx-aarch64/support/test/jtreg_test_thread_factory/jtregTestThreadFactory.jar -testThreadFactory:Virtual test/jdk/java/lang/FooTest.java
...
#section:main
----------messages:(7/204)----------
command: main FooTest
reason: User specified action: run main FooTest 
started: Sun Oct 29 19:12:33 IST 2023
Mode: agentvm
Agent id: 1
finished: Sun Oct 29 19:12:34 IST 2023
elapsed time (seconds): 0.211
----------System.out:(3/79)----------
Starting foo-bar thread
Throwing an exception from foo-bar
Test execution done
----------System.err:(6/223)----------
Exception in thread "foo-bar" java.lang.RuntimeException: Intentionally thrown exception
	at FooTest$AlwaysThrows.run(FooTest.java:32)
	at java.base/java.lang.Thread.run(Thread.java:1570)

JavaTest Message: Test complete.
result: Passed. Execution successful
test result: Passed. Execution successful


jtreg -report:files -verbose:summary -ea -esa -othervm -jdk:build/macosx-aarch64/images/jdk  -testThreadFactoryPath:.../build/macosx-aarch64/support/test/jtreg_test_thread_factory/jtregTestThreadFactory.jar -testThreadFactory:Virtual test/jdk/java/lang/FooTest.java
...
#section:main
----------messages:(6/191)----------
command: main FooTest
reason: User specified action: run main FooTest 
started: Sun Oct 29 19:13:22 IST 2023
Mode: othervm
finished: Sun Oct 29 19:13:22 IST 2023
elapsed time (seconds): 0.07
----------configuration:(0/0)----------
----------System.out:(3/79)----------
Starting foo-bar thread
Throwing an exception from foo-bar
Test execution done
----------System.err:(4/203)----------
Exception in thread "foo-bar" java.lang.RuntimeException: Intentionally thrown exception
  at FooTest$AlwaysThrows.run(FooTest.java:32)
  at java.base/java.lang.Thread.run(Thread.java:1570)
STATUS:Passed.

In both agentvm and othervm mode it is now marked as passed, which clearly is a change in behaviour and not a good thing.


So coming to the proposed solution in this PR. It proposes to do a `System.exit(1)` on a uncaught exception being thrown from within `Thread` running in test code. I think doing a System.exit isn't a good thing, even if it is expected to be a temporary solution. I noted previously that when running in agentvm mode with platform thread, jtreg doesn't kill/exit the agent JVM if there's an uncaught exception from with the test code. That's one of the reasons why System.exit isn't a good idea here. The other reason is, even if we did go with this System.exit approach, I think that will abruptly bring down the test infrastructure without it having a way to properly report about this test status. I went ahead and applied this proposed patch (to `Virtual` class) locally and ran my test again and as expected it shows that that JVM was abruptly shutdown and jtreg now reports:


Starting foo-bar thread
Throwing an exception from foo-bar
----------System.err:(3/158)----------
java.lang.RuntimeException: Intentionally thrown exception
    at FooTest$AlwaysThrows.run(FooTest.java:32)
    at java.base/java.lang.Thread.run(Thread.java:1570)
result: Error. Agent communication error: java.io.EOFException; check console log for any additional details


test result: Error. Agent communication error: java.io.EOFException; check console log for any additional details



I think to solve this correctly, this entire thing (perhaps even the virtual thread creation) needs to be done within the jtreg project where there's much more access to the internals of jtreg and there might be ways to detect these uncaught exceptions and report them cleanly as test failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1784125246

From abimpoudis at openjdk.org  Sun Oct 29 18:56:07 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sun, 29 Oct 2023 18:56:07 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v26]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add tests for new data types in switch statements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/fa6256b4..b391a48d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=24-25

  Stats: 74 lines in 1 file changed: 70 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From jbhateja at openjdk.org  Sun Oct 29 22:14:30 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 29 Oct 2023 22:14:30 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: <29iCeYY3SJrGjmd5gDsufdutIdfAcwYEPYOEo59G3IE=.73c69a72-1b19-4fd9-928b-a246f642e0ed@github.com>

On Fri, 27 Oct 2023 06:42:07 GMT, Xiaohong Gong  wrote:

>> sub-word gather do not emit any predicated instructions, thus only VectorMaskUseLoad is relevant in this context, however AVX512 and SVE does have a direct predicated gather instructions for 32/64 bit types.
>
> I see, thanks! `VecMaskUsePred` is added to check `match_rule_supported_vector_masked` for normal vector ops. That's because we may add an additional mask input for those vector ops. But `Load|StoreVectorScatterMasked` are different. They point to the masked operations no matter how they are implemented. So just `VecMaskUseLoad` is fine for all these two ops for me.

I think its better to align masked sub-word gather implementation with non-sub-word once i.e. support intrinsfication only for  predicated targets. Respective backends may then choose to either emit a predicated loop like the one which this patch does OR directly emit a predicated instruction if target support it.

With this we may see some performance penalty for masked sub-word gathers on non-predicated targets since original java implementation will now become fallback code, but then same penalty exists for non-subword gathers today.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1375522151

From jbhateja at openjdk.org  Sun Oct 29 22:25:29 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 29 Oct 2023 22:25:29 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 27 Oct 2023 08:04:47 GMT, Xiaohong Gong  wrote:

>> For x86 backend implementation we emit a gather loop hence index species is not used for sub-word, I am performing the index out of bound in a loop which operate a max integer vector granularity supported by target.
>> https://github.com/openjdk/jdk/pull/16354/files#diff-13cc2d6ec18e487ddae05cda671bdb6bb7ffd42ff7bc51a2e00c8c5e622bd55dR3641
>> 
>> Because there is cap on max integral vector size, thus for targets supporting direct sub-word gather instruction will have to emit an instruction sequence comprising of partial indexMap loads into integral vectors and issue multiple gather operations.
>
> I see, thanks for the explanation! It's different from SVE, which the index should be an int vector with the same length of the target vector.  We have to generate the index vectors. So the array length check to the given index map is necessary in java side.

Intrinsic still receive the indexArray and corresponding species with matching lane count OR maximally supported integral species otherwise. Due to lane size differences b/w sub-word and integer it may never be possible to have compatible species.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1375524154

From dholmes at openjdk.org  Mon Oct 30 08:04:39 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 30 Oct 2023 08:04:39 GMT
Subject: RFR: 8318737: Fallback linker passes bad JNI handle [v3]
In-Reply-To: 
References: <2iU7X5P-wSOUjFgsbdaneqjiTTXCYV8yYi4BrFsLPrA=.de15c282-ec69-419a-a85c-a958fc4dcf2f@github.com>
 
 
 
Message-ID: 

On Fri, 27 Oct 2023 09:09:05 GMT, Jorn Vernee  wrote:

> Do you want me to create a separate PR to remove the comment?

No not necessary. Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16349#issuecomment-1784664238

From dholmes at openjdk.org  Mon Oct 30 08:10:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 30 Oct 2023 08:10:31 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: 
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
 
Message-ID: 

On Sun, 29 Oct 2023 14:10:32 GMT, Jaikiran Pai  wrote:

>> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
>> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 
>> 
>> A few tests start failing.
>> 
>> The test
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
>> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.
>> 
>> The test
>> java/lang/Thread/virtual/ThreadAPI.java
>> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.
>> 
>> Test 
>> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.
>> 
>> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.
>
> Hello Leonid, in order to understand what exactly we are trying to solve here, I ran a few tests to see how things work without the changes being proposed in this PR. Here's my findings.
> 
> A bit of background first. When jtreg runs, either in agent mode or othervm mode, it creates a specific thread within which the actual test code runs. In either of these modes, it uses a custom jtreg specific `ThreadGroup` instance for this thread which is running the test code. This instance of `ThreadGroup` has specific overridden implementation of the `public void uncaughtException(Thread t, Throwable e)` API which keeps track of uncaught exception that might have been thrown by any threads that could have been spawned by the test. After `start()`ing the thread which runs the test code, the jtreg framework then waits for that thread to complete and once completed (either exceptionally or normally), jtreg framework then queries a state on the custom `ThreadGroup` instance to see if any uncaught exception(s) were received during the lifetime of this thread which ran that test. If it finds any, then it marks the test as failed and reports such a failure appropriately in the test re
 port. As noted, this applies for both the agent mode and other vm mode. Some important aspects of this implementation is that:
> 
> - The custom `ThreadGroup` which has the overridden implementation of the `uncaughtException(Thread t, Throwable e)` method doesn't interfere with the JVM level default exception handler.
> 
> - After the thread which ran the test code completes, the decision on whether to fail or pass a test is taken by checking the custom `ThreadGroup`'s state. Once this decision is done, the decision is immediately reported in relevant ways and the test status is marked (i.e. finalized) at this point.
> 
> - If this was running in agent vm mode, the agent vm mode continues to operate and isn't terminated and thus is available for subsequent tests. This point I think is important to remember for reasons that will be noted later in this comment.
> 
> Now coming to the part where in https://bugs.openjdk.org/browse/JDK-8303703 we introduced a way where jtreg instead of creating a platform thread (backed by its custom implementation of the `ThreadGroup`) to run the test code, now checks the presence of a `ThreadFactory` and if present, lets it create a `Thread` which runs this test code. In the JDK repo, we have an implementation of a `ThreadFactory` which creates a virtual thread instead of platform...

thanks for that detailed analysis @jaikiran ! I'm very uncomfortable with what is proposed in this PR.

I would hope that when jtreg uses the virtual thread factory then we could provide a wrapper that will execute the real task in a try/catch and allow any uncaught exceptions to be processed in the way jtreg needs them to be.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1784672682

From jlahoda at openjdk.org  Mon Oct 30 09:25:37 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 30 Oct 2023 09:25:37 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables &
 Patterns [v7]
In-Reply-To: <8a80EqSdoXu1bOUwloeZHStv8K0gnCScllreKIa4aYQ=.f4e97671-1d40-4eb8-b4d8-9b0c8d98845e@github.com>
References: 
 <8a80EqSdoXu1bOUwloeZHStv8K0gnCScllreKIa4aYQ=.f4e97671-1d40-4eb8-b4d8-9b0c8d98845e@github.com>
Message-ID: <13732p4eTxWPfWPYqQfCOQtxr-pIwfK-m_a9vqWrk8g=.4be46ecd-f8f5-4033-8262-234a48b031dd@github.com>

On Wed, 18 Oct 2023 10:29:32 GMT, Aggelos Biboudis  wrote:

>> This PR finalizes the feature of unnamed variables and patterns.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove preview lines from a new .out file

Marked as reviewed by jlahoda (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15649#pullrequestreview-1703632660

From abimpoudis at openjdk.org  Mon Oct 30 10:31:46 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 30 Oct 2023 10:31:46 GMT
Subject: Integrated: 8315532: Compiler Implementation for Unnamed Variables &
 Patterns
In-Reply-To: 
References: 
Message-ID: <8_E770JKHeFscUA1hxLwwonER6XtCh4bf2HtLOyF7z4=.38e3250f-e33a-4be0-9a3f-2d6304ccfd67@github.com>

On Sat, 9 Sep 2023 00:02:20 GMT, Aggelos Biboudis  wrote:

> This PR finalizes the feature of unnamed variables and patterns.

This pull request has now been integrated.

Changeset: c9d23c39
Author:    Aggelos Biboudis 
Committer: Jan Lahoda 
URL:       https://git.openjdk.org/jdk/commit/c9d23c39405ae3ed90e837753fdaec90c40129b8
Stats:     286 lines in 40 files changed: 133 ins; 89 del; 64 mod

8315532: Compiler Implementation for Unnamed Variables & Patterns
8317221: Implementation for javax.lang.model for Unnamed Variables & Patterns

Co-authored-by: Jan Lahoda 
Co-authored-by: Maurizio Cimadamore 
Co-authored-by: Gavin Bierman 
Co-authored-by: Brian Goetz 
Co-authored-by: Joe Darcy 
Co-authored-by: Aggelos Biboudis 
Reviewed-by: jlahoda, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/15649

From duke at openjdk.org  Mon Oct 30 10:59:39 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 30 Oct 2023 10:59:39 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com>
 
Message-ID: 

On Thu, 28 Sep 2023 15:01:25 GMT, Raffaello Giulietti  wrote:

>> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized.
>> 
>> The following are the test results based on MacBookPro M1 Pro: 
>> 
>> 
>> -Benchmark                          Mode  Cnt     Score     Error  Units
>> -StringFormat.complexFormat         avgt   15  1862.233 ? 217.479  ns/op
>> -StringFormat.int02Format           avgt   15   312.491 ?  26.021  ns/op
>> -StringFormat.intFormat             avgt   15    84.432 ?   4.145  ns/op
>> -StringFormat.longFormat            avgt   15    87.330 ?   6.111  ns/op
>> -StringFormat.stringFormat          avgt   15    63.985 ?  11.366  ns/op
>> -StringFormat.stringIntFormat       avgt   15    87.422 ?   0.147  ns/op
>> -StringFormat.widthStringFormat     avgt   15   250.740 ?  32.639  ns/op
>> -StringFormat.widthStringIntFormat  avgt   15   312.474 ?  16.309  ns/op
>> 
>> +Benchmark                          Mode  Cnt    Score    Error  Units
>> +StringFormat.complexFormat         avgt   15  740.626 ? 66.671  ns/op (+151.45)
>> +StringFormat.int02Format           avgt   15  131.049 ?  0.432  ns/op (+138.46)
>> +StringFormat.intFormat             avgt   15   67.229 ?  4.155  ns/op (+25.59)
>> +StringFormat.longFormat            avgt   15   66.444 ?  0.614  ns/op (+31.44)
>> +StringFormat.stringFormat          avgt   15   62.619 ?  4.652  ns/op (+2.19)
>> +StringFormat.stringIntFormat       avgt   15   89.606 ? 13.966  ns/op (-2.44)
>> +StringFormat.widthStringFormat     avgt   15   52.462 ? 15.649  ns/op (+377.95)
>> +StringFormat.widthStringIntFormat  avgt   15  101.814 ?  3.147  ns/op (+206.91)
>
> Meaningful external reviews take a _lot_ of engineering time on such a popular platform as the JDK.
> They make sense only on somehow stable code, otherwise they are a waste of human resources.
> 
> So sure, take your time to stabilize your code, make your tests, but please refrain from keep on changing too much once you publish a PR. If reviewers have to face continuous changes, they might become uninterested in reviewing.

@rgiulietti Is there anything else that needs to be modified?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1784943302

From me at tylerkindy.com  Mon Oct 30 11:14:17 2023
From: me at tylerkindy.com (Tyler Kindy)
Date: Mon, 30 Oct 2023 07:14:17 -0400
Subject: Update on JEP-461: Stream Gatherers (Preview)
Message-ID: <6C305EB0-888D-4FCE-B3C9-AA0D5321EC85@tylerkindy.com>

An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Mon Oct 30 11:57:09 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 11:57:09 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v7]
In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
Message-ID: <-BQ5YEKmJWW22k_ib3jV3i4GxgwctvW6BokEvuWopqE=.54bf3af7-4aac-4a91-81a8-e900df08a405@github.com>

> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose:
> 
> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge
> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead.
> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. 
> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead.
> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size.
> - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory
> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested.
> 
> These speedups reduced the runtime from 4 min 17 sec to 4 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 2 GB. Memory consumption is down from 8GB to something like 12MB.

Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Run CenSizeTooLarge automatically, since it no longer requires excessive memory or disk space
 - Use a SparseOutputStream to reduce required diskspace from 2GB to 4K. SparseOutputStream writes 'holes' instead of actual bytes until the final CEN is written.
 - TestTooManyEntries is renamed to CenSizeTooLarge
 - Merge branch 'master' into cen-size-too-large
 - MAX_EXTRA_FIELD_SIZE can be better expressed as 0xFFFF
 - Bring back '@requires sun.arch.data.model == 64' for now
 - Spell 'specified' correctly
 - Give test method a long, meaningful name
 - Remove blank line
 - Make CEN headers maximally large such that we need fewer of them and save memory
 - ... and 4 more: https://git.openjdk.org/jdk/compare/33a18950...9629b8d2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12991/files
  - new: https://git.openjdk.org/jdk/pull/12991/files/a1a77192..9629b8d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=05-06

  Stats: 1001917 lines in 12941 files changed: 671061 ins; 209198 del; 121658 mod
  Patch: https://git.openjdk.org/jdk/pull/12991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12991/head:pull/12991

PR: https://git.openjdk.org/jdk/pull/12991

From duke at openjdk.org  Mon Oct 30 12:01:34 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 12:01:34 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v3]
In-Reply-To: 
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
 
 
Message-ID: 

On Sun, 12 Mar 2023 14:12:08 GMT, Lance Andersen  wrote:

>> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Integer.toString instead of Long.toString
>
>> Here's a wild idea:
>> 
>> We could inject large extra fields on the CEN entries to inflate the size of each CEN entry. This means we get away with much fewer CEN entries which again means much less memory. Also, writing mostly empty extra data seems to be really fast, at least on my Macbook Pro.
>> 
>> For me, the test now run without the `@requires' and completes in less than 5 seconds.
>> 
>> The cost is slightly more complicated code. But perhaps still worth the added complexity?
>> 
>> ```java
>> @BeforeTest
>> public void setup() throws IOException {
>>     hugeZipFile = new File("cen-too-large.zip");
>>     hugeZipFile.deleteOnExit();
>> 
>>     // Length of generated entry names
>>     int nameLength = 10;
>> 
>>     // We use a large extra field to get away with fewer CEN headers
>>     byte[] extra = makeLargeExtra();
>> 
>>     // The size of a single CEN header, including name and extra field
>>     int cenHeaderSize = ZipFile.CENHDR + nameLength + extra.length;
>> 
>>     // Determine the number of entries needed to exceed the MAX_CEN_SIZE
>>     int numEntries = (MAX_CEN_SIZE / cenHeaderSize) + 1;
>> 
>>     ZipEntry[] entries = new ZipEntry[numEntries];
>>     try (ZipOutputStream zip = new ZipOutputStream(new BufferedOutputStream(new FileOutputStream(hugeZipFile)))) {
>>         // Creating the LocalDataTime once allows faster processing
>>         LocalDateTime time = LocalDateTime.now();
>>         // Add entries until MAX_CEN_SIZE is reached
>>         for (int i = 0; i < numEntries; i++) {
>>             String name = Integer.toString(i);
>>             name = "0".repeat(nameLength -name.length()) + name;
>>             ZipEntry entry = entries[i] = new ZipEntry(name);
>>             // Use STORED for faster processing
>>             entry.setMethod(ZipEntry.STORED);
>>             entry.setSize(0);
>>             entry.setCrc(0);
>>             entry.setTimeLocal(time);
>>             zip.putNextEntry(entry);
>>         }
>>         zip.closeEntry();
>>         for (ZipEntry entry : entries) {
>>             entry.setExtra(extra);
>>         }
>>     }
>> }
>> 
>> /**
>>  * Make an extra field with an 'unknown' tag and the maximum possible data size
>>  * @return
>>  */
>> private static byte[] makeLargeExtra() {
>>     byte[] extra = new byte[Short.MAX_VALUE];
>>     ByteBuffer buffer = ByteBuffer.wrap(extra).order(ByteOrder.LITTLE_ENDIAN);
>>     buffer.putShort((short) 0x9902); // 'unknown' tag
>>     buffer.putShort((short) (extra.length - 2 * Short.BYTES)); // Data size
>>     return e...

This PR was reviewed by @LanceAndersen and @Martin-Buchholz back in May, but unfortunately did not get integrated before it was closed for inactivity.

I'm reopening it now, with a few changes after the last reviews:

- To save disk space required by the test, a SparseOutputStream writes 'holes' until it detects that the last CEN is written, after which it starts writing actual bytes for the END header. This reduces the required disk space from ~2GB to ~4K.
- Since the test no longer requires excessive memory or disk space, the 'manual' tag is removed and the test is removed from the `jdk_core_manual_no_input` group in `TEST.groups`

With a blessing of these last changes on top of what's already reviewed, I'm hoping to integrate this PR soonish. 

And sorry for the long-lived PR, I can only blame it on the unusually great summer in the north of Norway this year :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12991#issuecomment-1785034602

From duke at openjdk.org  Mon Oct 30 12:16:34 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 12:16:34 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v3]
In-Reply-To: 
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
 
 
 
Message-ID: <8-6wXmCKNsCXaOoTxmKsGycIEOcmrjMUyZWIBU9fBgg=.11832ae5-8e2f-489d-81df-291629cfc8c6@github.com>

On Sun, 12 Mar 2023 11:21:18 GMT, Eirik Bjorsnos  wrote:

> I think the changes look good overall. Thank you for this. I am not sure that the `@requires` is needed at this point.

Was the `@requires (sun.arch.data.model == "64")` added to satisfy the 8GB memory requirement? If so, I guess we can safely remove the requires tag, even though the test still creates a ~2GB sparse file?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12991#issuecomment-1785057458

From pminborg at openjdk.org  Mon Oct 30 13:26:32 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 30 Oct 2023 13:26:32 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[] [v2]
In-Reply-To: <921yYu0_nR0vNTFnKosdaUwXddiZO4BSuVB2LgXg23U=.ebaf87ff-5144-4efc-9d4e-fdee76efd760@github.com>
References: 
 <921yYu0_nR0vNTFnKosdaUwXddiZO4BSuVB2LgXg23U=.ebaf87ff-5144-4efc-9d4e-fdee76efd760@github.com>
Message-ID: 

On Thu, 26 Oct 2023 09:17:25 GMT, Per Minborg  wrote:

>> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow unaligned array access

Here is a test showing there is a need to improve performance for certain combinations of load operations. It is likely, the same is true for store operations.


Benchmark                                                   (size)  Mode  Cnt     Score     Error  Units
TestLoadSegmentVarious.byteVectorFromByteBackedSegment        1024  avgt   10   280.008 ?   7.251  ns/op
TestLoadSegmentVarious.byteVectorFromDoubleBackedSegment      1024  avgt   10  1304.008 ?  98.901  ns/op
TestLoadSegmentVarious.byteVectorFromIntBackedSegment         1024  avgt   10  1279.621 ? 100.008  ns/op
TestLoadSegmentVarious.doubleVectorFromByteBackedSegment      1024  avgt   10    37.281 ?   1.360  ns/op
TestLoadSegmentVarious.doubleVectorFromDoubleBackedSegment    1024  avgt   10    36.847 ?   0.130  ns/op
TestLoadSegmentVarious.doubleVectorFromIntBackedSegment       1024  avgt   10   194.195 ?  31.096  ns/op
TestLoadSegmentVarious.intVectorFromByteBackedSegment         1024  avgt   10    72.602 ?   1.768  ns/op
TestLoadSegmentVarious.intVectorFromDoubleBackedSegment       1024  avgt   10   166.851 ?   9.528  ns/op
TestLoadSegmentVarious.intVectorFromIntBackedSegment          1024  avgt   10    71.283 ?   0.507  ns/op
TestLoadSegmentVarious.scalarByteVectorFromByteSegment        1024  avgt   10  4790.084 ?  45.882  ns/op
TestLoadSegmentVarious.scalarByteVectorFromDoubleSegment      1024  avgt   10  4841.273 ? 291.962  ns/op
TestLoadSegmentVarious.scalarByteVectorFromIntSegment         1024  avgt   10  4794.028 ? 101.282  ns/op
TestLoadSegmentVarious.scalarDoubleVectorFromByteSegment      1024  avgt   10  1241.117 ?  11.603  ns/op
TestLoadSegmentVarious.scalarDoubleVectorFromDoubleSegment    1024  avgt   10  1245.752 ?  15.516  ns/op
TestLoadSegmentVarious.scalarDoubleVectorFromIntSegment       1024  avgt   10  1232.216 ?   8.365  ns/op
TestLoadSegmentVarious.scalarIntVectorFromByteSegment         1024  avgt   10  1239.146 ?  14.582  ns/op
TestLoadSegmentVarious.scalarIntVectorFromDoubleSegment       1024  avgt   10  1236.712 ?   8.063  ns/op
TestLoadSegmentVarious.scalarIntVectorFromIntSegment          1024  avgt   10  1228.656 ?   3.329  ns/op


As can be seen, vector performance for `IntVector` and `DoubleVector` is good for operations from a byte array or where the array types match.

This work can be made under a separate issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16360#issuecomment-1785186113

From pminborg at openjdk.org  Mon Oct 30 13:43:13 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 30 Oct 2023 13:43:13 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[] [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add benchmark and intrinsification spy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16360/files
  - new: https://git.openjdk.org/jdk/pull/16360/files/4828a98b..c104051c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16360&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16360&range=01-02

  Stats: 420 lines in 3 files changed: 419 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16360/head:pull/16360

PR: https://git.openjdk.org/jdk/pull/16360

From rgiulietti at openjdk.org  Mon Oct 30 14:01:38 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 30 Oct 2023 14:01:38 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 11 Oct 2023 15:45:29 GMT, Brian Burkhalter  wrote:

>> Change test to use `RandomFactory` instead of `new Random()` and convert it to JUnit 5.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313621: assertTrue -> assertEquals

test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal.java line 65:

> 63: /**
> 64:  * @test
> 65:  * @bug 7032154

Suggestion:

 * @bug 7032154 8313621

test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal.java line 78:

> 76:  */
> 77: public class TestFloatingDecimal {
> 78:     private static final int NUM_RANDOM_TESTS = 100000;

Suggestion:

    private static final int NUM_RANDOM_TESTS = 100_000;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16130#discussion_r1376266315
PR Review Comment: https://git.openjdk.org/jdk/pull/16130#discussion_r1376266653

From lancea at openjdk.org  Mon Oct 30 14:32:47 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Oct 2023 14:32:47 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v7]
In-Reply-To: <-BQ5YEKmJWW22k_ib3jV3i4GxgwctvW6BokEvuWopqE=.54bf3af7-4aac-4a91-81a8-e900df08a405@github.com>
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
 <-BQ5YEKmJWW22k_ib3jV3i4GxgwctvW6BokEvuWopqE=.54bf3af7-4aac-4a91-81a8-e900df08a405@github.com>
Message-ID: <3UYlMCBWsb3h-Dv0ScVjQ7qrlOHVdDuR8BkKOsyWY-E=.ec38e8ce-78bb-4fe8-bfec-8770fa3a1d24@github.com>

On Mon, 30 Oct 2023 11:57:09 GMT, Eirik Bjorsnos  wrote:

>> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose:
>> 
>> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge
>> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead.
>> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. 
>> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead.
>> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size.
>> - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory
>> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested.
>> - By writing sparse 'holes' until the last CEN entry, we can reduce required disk space.
>> 
>> These speedups reduced the runtime from 4 min 17 sec to 3 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to ~4K. Memory consumption is down from 8GB to something like 12MB.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Run CenSizeTooLarge automatically, since it no longer requires excessive memory or disk space
>  - Use a SparseOutputStream to reduce required diskspace from 2GB to 4K. SparseOutputStream writes 'holes' instead of actual bytes until the final CEN is written.
>  - TestTooManyEntries is renamed to CenSizeTooLarge
>  - Merge branch 'master' into cen-size-too-large
>  - MAX_EXTRA_FIELD_SIZE can be better expressed as 0xFFFF
>  - Bring back '@requires sun.arch.data.model == 64' for now
>  - Spell 'specified' correctly
>  - Give test method a long, meaningful name
>  - Remove blank line
>  - Make CEN headers maximally large such that we need fewer of them and save memory
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/f5d01b56...9629b8d2

Thanks for restarting the discussion on this test clean up.

Please see comments below

test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 33:

> 31: import org.testng.annotations.BeforeTest;
> 32: import org.testng.annotations.Test;
> 33: 

As this will be a new test, could you please consider converting to junit.

test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 139:

> 137:     public void centralDirectoryTooLargeToFitInByteArray() {
> 138:         ZipException ex = expectThrows(ZipException.class, () -> new ZipFile(hugeZipFile));
> 139:         assertEquals(ex.getMessage(), "invalid END header (central directory size too large)");

Could be have the expected message a class constant so that if this message ever changes it is easier to find/update

test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 187:

> 185:             } else {
> 186:                 channel.position(position);
> 187:                 if (Arrays.equals(LAST_COMMENT_BYTES, 0, LAST_COMMENT_BYTES.length, b, off, len)) {

I would suggest a comment to help future developers.  I realize there are some earlier bread crumbs but I think this would be beneficial

-------------

PR Review: https://git.openjdk.org/jdk/pull/12991#pullrequestreview-1704236482
PR Review Comment: https://git.openjdk.org/jdk/pull/12991#discussion_r1376286075
PR Review Comment: https://git.openjdk.org/jdk/pull/12991#discussion_r1376295495
PR Review Comment: https://git.openjdk.org/jdk/pull/12991#discussion_r1376302371

From lancea at openjdk.org  Mon Oct 30 14:32:49 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Oct 2023 14:32:49 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v3]
In-Reply-To: <8-6wXmCKNsCXaOoTxmKsGycIEOcmrjMUyZWIBU9fBgg=.11832ae5-8e2f-489d-81df-291629cfc8c6@github.com>
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
 
 
 
 <8-6wXmCKNsCXaOoTxmKsGycIEOcmrjMUyZWIBU9fBgg=.11832ae5-8e2f-489d-81df-291629cfc8c6@github.com>
Message-ID: 

On Mon, 30 Oct 2023 12:13:59 GMT, Eirik Bjorsnos  wrote:

> > I think the changes look good overall. Thank you for this. I am not sure that the `@requires` is needed at this point.
> 
> Was the `@requires (sun.arch.data.model == "64")` added to satisfy the 8GB memory requirement? If so, I guess we can safely remove the requires tag, even though the test still creates a ~2GB sparse file?


We would have to run across all of the mach5 platforms to verify.  You could remove it for now and we go from here

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12991#issuecomment-1785341362

From lancea at openjdk.org  Mon Oct 30 14:32:50 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Oct 2023 14:32:50 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v6]
In-Reply-To: 
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
 
 
 
Message-ID: <_z1rKC030HaAl6F5zr1jnBS9cEVjzkj3uEXb03gkSFk=.0504bf96-7b59-470e-b6f3-10b8447d1e08@github.com>

On Mon, 13 Mar 2023 03:18:26 GMT, Eirik Bjorsnos  wrote:

>> test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 53:
>> 
>>> 51: 
>>> 52:     // Maximum size (unsigned short) of an extra field allowed by the standard
>>> 53:     static final int MAX_EXTRA_FIELD_SIZE = 0XFFFF;
>> 
>> 4.4.10 file name length: (2 bytes)
>>    4.4.11 extra field length: (2 bytes)
>>    4.4.12 file comment length: (2 bytes)
>> 
>>        The length of the file name, extra field, and comment
>>        fields respectively.  The combined length of any
>>        directory record and these three fields SHOULD NOT
>>        generally exceed 65,535 bytes.
>
> `The combined length of any directory record and these three fields SHOULD NOT generally exceed 65,535 bytes.`
> 
> I was not aware of this 'combined length' clause. Are you suggesting we take this into account in this test? I feel that would be somewhat strange, given that this constraint seems not be be enforced at all by ZipEntry or ZipOutputStream:
> 
> 
> ZipEntry(String name):
> 
> if (name.length() > 0xFFFF) {
>     throw new IllegalArgumentException("entry name too long");
> }
> 
> 
> 
> ZipOutputStream.writeCEN:
> 
> if (commentBytes != null) {
>     writeBytes(commentBytes, 0, Math.min(commentBytes.length, 0xffff));
> }

I would clarify the comment a bit and perhaps point to the comments Martin mentions in the review above

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12991#discussion_r1376284800

From viktor.klang at oracle.com  Mon Oct 30 14:39:29 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 30 Oct 2023 14:39:29 +0000
Subject: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)
In-Reply-To: <6C305EB0-888D-4FCE-B3C9-AA0D5321EC85@tylerkindy.com>
References: <6C305EB0-888D-4FCE-B3C9-AA0D5321EC85@tylerkindy.com>
Message-ID: 

Hi Tyler,

Thank you for the kind words -- they are much appreciated. And you have a very good question indeed!

My thinking behind making fold a Gatherer is that I think that it is strictly more powerful than "only" having it as a collector (It wouldn't be able to be a Collector since you'd need a combiner for it, but also being able to compose it with other operations, choosing the output type at a later stage in the process, and so forth).

Also, if you think about it -- single-element Streams are just as valid as empty Streams, N-sized Streams, or even unbounded Streams, and conceptually, there's no difference between the following two Streams:

var a = Stream.of("1234")
var b = Stream.of(1,2,3,4).gather(fold(() -> "", (str, next) -> str + next))

So that was my thinking?allow developers to stay within Stream processing for as long as they want, and choose the terminal operation when they need to break out from the Stream.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Tyler Kindy 
Sent: Monday, 30 October 2023 12:14
To: Viktor Klang 
Cc: core-libs-dev at openjdk.org 
Subject: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)

?
?Thanks for the JEP and your talk, Viktor! I think `Stream::gather` will be super useful in my day-to-day as a Java developer.

I?m curious why `fold` is being implemented with gatherers. I recognize `Gatherer` is designed to support intermediate operations, but `fold` feels inherently like a terminal operation to me since it, like `reduce` or `collect`, consumes all the elements in the stream and produces a single result.

Is there a technical limitation to making `fold` a terminal operation? For example, does `Collector` inherently presume parallelization in a way that `Gatherer` does not?

Or is the idea mainly to demonstrate the power of gatherers, and we could also make `fold` a terminal operation with the current `Stream` API?

Thank you!
Tyler Kindy

On Oct 27, 2023, at 9:50?AM, Viktor Klang  wrote:

Greetings,

As you may have already seen, Stream Gatherers is now a Preview JEP with Candidate status

Work-in-progress (interfaces, implementation, tests, benches, and documentation) for JEP-461 is currently available here.

While the design has held up well, there are some important improvements made since the original design document was written.

Notable changes (without any particular order):

  *   Stream::gather() now has a default implementation.

  *   Gatherer::supplier() was renamed to Gatherer::initializer() to better reflect intent.

  *   Gatherer.Sink was renamed to Gatherer.Downstream to better signal what it represents.

  *   Gatherer::collect(Collector) and its companion type Gatherer.ThenCollector was dropped due to compatibility concerns with existing code which operates on Collector.

  *
Gatherer.Characteristics have been eliminated and superseded by having default values that are used as sentinels.
 (discussed further down the list)
This is important because with the Characteristics-model keeping alignment between Characteristics and actual implementation proved brittle, and under composition of Gatherers computing the union was inefficient and mostly lead to an empty set in the end.

  *   Gatherer.defaultInitializer(), Gatherer.defaultCombiner(), and Gatherer.defaultFinisher() were added as static methods?these are the sentinels used to elide calling the initializer, to elide calling the combiner (avoid parallelization), and to elide calling the finisher, respectively.

  *   Gatherer::initializer(), Gatherer::combiner(), and Gatherer::finisher() default implementations return the respective sentinels.

  *   A subtype of Integrator named Greedy was added, together with a factory method to guide lambda-to-nominal-type conversion. This allows creators of Gatherers to signal that an Integrator will never initiate a short-circuit (but may relay one from downstream), and that is available during evaluation to determine if the operation can short-circuit or not.

  *   Factories for creating anonymous Gatherers were expanded upon to include Gatherer.of() and Gatherer.ofSequential() with different sets of parameters, primarily to make it more ergonomical and easier to read and write the code using those factories.

  *   A curated set of initial built-in Gatherers is located in java.util.stream.Gatherers

I recently presented Gatherers at Devoxx, which I'd recommend watching for an introduction to the feature.

Teaching old Streams new tricks By Viktor Klang
Have you ever wanted to perform an operation on a java.util.stream.Stream only to find that the existing set of operations didn't provide what you needed?forcing you to break out early from the Stream and perform the logic outside of it? As a matter of fact, java.util.stream was the first JDK API designed with lambdas in mind and was ...
www.youtube.com
??????

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vklang at openjdk.org  Mon Oct 30 14:59:53 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 30 Oct 2023 14:59:53 GMT
Subject: RFR: JDK-8318467 : [jmh] tests concurrent.Queues and
 concurrent.ProducerConsumer hang with 101+ threads
Message-ID: 

Discussed with @DougLea and adjusting the queue capacity to at least the number of participating threads seems like the most sensible fix.

-------------

Commit messages:
 - Addressing 8318467 by adjusting queue capacity to at least the number of threads

Changes: https://git.openjdk.org/jdk/pull/16419/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16419&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318467
  Stats: 11 lines in 2 files changed: 7 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16419/head:pull/16419

PR: https://git.openjdk.org/jdk/pull/16419

From dl at openjdk.org  Mon Oct 30 15:03:41 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 30 Oct 2023 15:03:41 GMT
Subject: RFR: JDK-8318467 : [jmh] tests concurrent.Queues and
 concurrent.ProducerConsumer hang with 101+ threads
In-Reply-To: 
References: 
Message-ID: 

On Mon, 30 Oct 2023 14:54:08 GMT, Viktor Klang  wrote:

> Discussed with @DougLea and adjusting the queue capacity to at least the number of participating threads seems like the most sensible fix.

Thanks for figuring out where to make the adjustment! Looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16419#issuecomment-1785410197

From lancea at openjdk.org  Mon Oct 30 15:05:47 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Oct 2023 15:05:47 GMT
Subject: RFR: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test [v8]
In-Reply-To: <--iBU8TPNfvfxtOg2suRlEq1wFf55iFZCE_4N9hw9Ww=.52d201f9-89dc-441b-a260-53d5a8f49ef4@github.com>
References: 
 <--iBU8TPNfvfxtOg2suRlEq1wFf55iFZCE_4N9hw9Ww=.52d201f9-89dc-441b-a260-53d5a8f49ef4@github.com>
Message-ID: 

On Sat, 28 Oct 2023 20:01:56 GMT, Eirik Bjorsnos  wrote:

>> Please review this PR which brings  the DataDescriptorSignatureMissing test back to life.
>> 
>> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` 
>> 
>> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically.
>
> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into signature-less-data-descriptor
>    
>    # Conflicts:
>    #	test/jdk/java/util/zip/DataDescriptorSignatureMissing.java
>  - The END header LOC offset field and the second entry's CEN LOC offset fields need to be update to account for the four missing signature bytes.
>  - Merge branch 'master' into signature-less-data-descriptor
>  - Add assertNotNulls to catch unexpectedly missing entries
>  - Revert change to Google copyright line, add an Oracle copyright line instead.
>  - Use "Signatureless" consistently
>  - Remove reference to python in the @summary of DataDescriptorSignatureMissing
>  - Update copyright years
>  - Add method comments
>  - Instead of calling out to python, create a ZIP file and remove the data descriptor signature.

Thanks for trying to move this forward.  Please see my comments below.

Another question, is the zip that is generated by this test readable by other zip tools such as info-zip, Apache Common-compress, winzip?

test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 3:

> 1: /*
> 2:  * Copyright 2012 Google, Inc.  All Rights Reserved.
> 3:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

I am not sure the copyright can be updated this way @irisclark, could you provide guidance

test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 34:

> 32:  * without data descriptors was found.
> 33:  * @run testng DataDescriptorSignatureMissing
> 34:  */

Can we convert this please to use junit

test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 76:

> 74:     /**
> 75:      * Produce a ZIP file where the first entry has a signature-less data descriptor
> 76:      */

I think it would be useful to show the  what the internal zip representation of the LOC and CEN looks like to make it clear what a signature-less data descriptor is meant to be for future maintainers

-------------

PR Review: https://git.openjdk.org/jdk/pull/12959#pullrequestreview-1704351462
PR Review Comment: https://git.openjdk.org/jdk/pull/12959#discussion_r1376354980
PR Review Comment: https://git.openjdk.org/jdk/pull/12959#discussion_r1376355486
PR Review Comment: https://git.openjdk.org/jdk/pull/12959#discussion_r1376360218

From vklang at openjdk.org  Mon Oct 30 15:07:49 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 30 Oct 2023 15:07:49 GMT
Subject: RFR: JDK-8318467 : [jmh] tests concurrent.Queues and
 concurrent.ProducerConsumer hang with 101+ threads [v2]
In-Reply-To: 
References: 
Message-ID: 

> Discussed with @DougLea and adjusting the queue capacity to at least the number of participating threads seems like the most sensible fix.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Updating copyright year and adjusting whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16419/files
  - new: https://git.openjdk.org/jdk/pull/16419/files/f4afe57e..f7a12af9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16419&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16419&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16419/head:pull/16419

PR: https://git.openjdk.org/jdk/pull/16419

From vklang at openjdk.org  Mon Oct 30 15:07:50 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 30 Oct 2023 15:07:50 GMT
Subject: RFR: JDK-8318467 : [jmh] tests concurrent.Queues and
 concurrent.ProducerConsumer hang with 101+ threads
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 30 Oct 2023 15:01:02 GMT, Doug Lea 
 wrote:

>> Discussed with @DougLea and adjusting the queue capacity to at least the number of participating threads seems like the most sensible fix.
>
> Thanks for figuring out where to make the adjustment! Looks good.

@DougLea Yeah it took some digging to find the right approach ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16419#issuecomment-1785415180

From duke at openjdk.org  Mon Oct 30 15:25:02 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 15:25:02 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v8]
In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
Message-ID: 

> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose:
> 
> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge
> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead.
> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. 
> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead.
> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size.
> - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory
> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested.
> - By writing sparse 'holes' until the last CEN entry, we can reduce required disk space.
> 
> These speedups reduced the runtime from 4 min 17 sec to 3 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to ~4K. Memory consumption is down from 8GB to something like 12MB.

Eirik Bjorsnos has updated the pull request incrementally with four additional commits since the last revision:

 - Extract the expected ZipException message into a class constant
 - Add comment explaining the MAX_EXTRA_FIELD_SIZE constant
 - Convert test to junit
 - Remove @requires for sun.arch.data.model == "64", assuming the updated test doesn't need it.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12991/files
  - new: https://git.openjdk.org/jdk/pull/12991/files/9629b8d2..c21789b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=06-07

  Stats: 27 lines in 1 file changed: 17 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12991/head:pull/12991

PR: https://git.openjdk.org/jdk/pull/12991

From duke at openjdk.org  Mon Oct 30 15:28:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 15:28:37 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v3]
In-Reply-To: 
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
 
 
 
 <8-6wXmCKNsCXaOoTxmKsGycIEOcmrjMUyZWIBU9fBgg=.11832ae5-8e2f-489d-81df-291629cfc8c6@github.com>
 
Message-ID: 

On Mon, 30 Oct 2023 14:29:41 GMT, Lance Andersen  wrote:

> > Was the `@requires (sun.arch.data.model == "64")` added to satisfy the 8GB memory requirement? If so, I guess we can safely remove the requires tag, even though the test still creates a ~2GB sparse file?
> 
> We would have to run across all of the mach5 platforms to verify. You could remove it for now and we go from here

Removed it for now, let's see what the bots say.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12991#issuecomment-1785461403

From duke at openjdk.org  Mon Oct 30 15:28:51 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 15:28:51 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v7]
In-Reply-To: <3UYlMCBWsb3h-Dv0ScVjQ7qrlOHVdDuR8BkKOsyWY-E=.ec38e8ce-78bb-4fe8-bfec-8770fa3a1d24@github.com>
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
 <-BQ5YEKmJWW22k_ib3jV3i4GxgwctvW6BokEvuWopqE=.54bf3af7-4aac-4a91-81a8-e900df08a405@github.com>
 <3UYlMCBWsb3h-Dv0ScVjQ7qrlOHVdDuR8BkKOsyWY-E=.ec38e8ce-78bb-4fe8-bfec-8770fa3a1d24@github.com>
Message-ID: 

On Mon, 30 Oct 2023 14:10:25 GMT, Lance Andersen  wrote:

>> Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Run CenSizeTooLarge automatically, since it no longer requires excessive memory or disk space
>>  - Use a SparseOutputStream to reduce required diskspace from 2GB to 4K. SparseOutputStream writes 'holes' instead of actual bytes until the final CEN is written.
>>  - TestTooManyEntries is renamed to CenSizeTooLarge
>>  - Merge branch 'master' into cen-size-too-large
>>  - MAX_EXTRA_FIELD_SIZE can be better expressed as 0xFFFF
>>  - Bring back '@requires sun.arch.data.model == 64' for now
>>  - Spell 'specified' correctly
>>  - Give test method a long, meaningful name
>>  - Remove blank line
>>  - Make CEN headers maximally large such that we need fewer of them and save memory
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/f5cb971b...9629b8d2
>
> test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 33:
> 
>> 31: import org.testng.annotations.BeforeTest;
>> 32: import org.testng.annotations.Test;
>> 33: 
> 
> As this will be a new test, could you please consider converting to junit.

- Added a comment explaining the chosen value for the constant, referencing APPNOTE.TXT 
- Converted the test to JUnit (even remembered to swap argument order of assertEquals!)

> test/jdk/java/util/zip/ZipFile/CenSizeTooLarge.java line 139:
> 
>> 137:     public void centralDirectoryTooLargeToFitInByteArray() {
>> 138:         ZipException ex = expectThrows(ZipException.class, () -> new ZipFile(hugeZipFile));
>> 139:         assertEquals(ex.getMessage(), "invalid END header (central directory size too large)");
> 
> Could be have the expected message a class constant so that if this message ever changes it is easier to find/update

Extracted the expected ZipException message to a class constant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12991#discussion_r1376407892
PR Review Comment: https://git.openjdk.org/jdk/pull/12991#discussion_r1376408869

From duke at openjdk.org  Mon Oct 30 15:36:05 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 15:36:05 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v9]
In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
Message-ID: 

> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose:
> 
> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge
> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead.
> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. 
> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead.
> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size.
> - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory
> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested.
> - By writing sparse 'holes' until the last CEN entry, we can reduce required disk space.
> 
> These speedups reduced the runtime from 4 min 17 sec to 3 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to ~4K. Memory consumption is down from 8GB to something like 12MB.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Add a code comment explaining the writing of a sparse file until the last CEN

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12991/files
  - new: https://git.openjdk.org/jdk/pull/12991/files/c21789b0..8f1b0186

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=07-08

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12991/head:pull/12991

PR: https://git.openjdk.org/jdk/pull/12991

From duke at openjdk.org  Mon Oct 30 15:50:49 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 15:50:49 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v10]
In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
Message-ID: 

> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose:
> 
> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge
> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead.
> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. 
> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead.
> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size.
> - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory
> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested.
> - By writing sparse 'holes' until the last CEN entry, we can reduce required disk space.
> 
> These speedups reduced the runtime from 4 min 17 sec to 3 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to ~4K. Memory consumption is down from 8GB to something like 12MB.

Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:

  Replace the 'afterLastCEN' boolean with a 'sparse' state variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12991/files
  - new: https://git.openjdk.org/jdk/pull/12991/files/8f1b0186..c3d0069f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12991&range=08-09

  Stats: 15 lines in 1 file changed: 6 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12991/head:pull/12991

PR: https://git.openjdk.org/jdk/pull/12991

From duke at openjdk.org  Mon Oct 30 15:50:50 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 15:50:50 GMT
Subject: RFR: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
 [v7]
In-Reply-To: <3UYlMCBWsb3h-Dv0ScVjQ7qrlOHVdDuR8BkKOsyWY-E=.ec38e8ce-78bb-4fe8-bfec-8770fa3a1d24@github.com>
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
 <-BQ5YEKmJWW22k_ib3jV3i4GxgwctvW6BokEvuWopqE=.54bf3af7-4aac-4a91-81a8-e900df08a405@github.com>
 <3UYlMCBWsb3h-Dv0ScVjQ7qrlOHVdDuR8BkKOsyWY-E=.ec38e8ce-78bb-4fe8-bfec-8770fa3a1d24@github.com>
Message-ID: 

On Mon, 30 Oct 2023 14:28:28 GMT, Lance Andersen  wrote:

> Please see comments below

Big thanks for your review Lance! I think I have addressed your concerns now.

> I would suggest a comment to help future developers. I realize there are some earlier bread crumbs but I think this would be beneficial

I added a code comment explaining here, and also replaced the `afterLastCEN` variable with a `sparse` variable, flipping the if statements accordingly. Sparse is the 'normal' in this context, so better to have actual writes in the `else` branch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12991#issuecomment-1785506785
PR Review Comment: https://git.openjdk.org/jdk/pull/12991#discussion_r1376441175

From aph at openjdk.org  Mon Oct 30 16:03:46 2023
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 30 Oct 2023 16:03:46 GMT
Subject: RFR: JDK-8319120: Unbound ScopedValue.get() throws the wrong exception
Message-ID: 

The bug here is a thinko in `ScopedValue.scopedValueBindings()`.

If the JVM runs out of resources, we throw a `VirtualMachineError`. Running out of resources can happen at almost any time, and can happen while `ScopedValue`'s internal structures are being modified, leaving them in an inconsistent state. We detect when a `VirtualMachineError` happens and walk the stack to find the most-recent set of `ScopedValue` bindings.

When we crate a new `Thread`, we push a sentinel frame onto the stack that we can find in the case that we threw a `VirtualMachineError`. Threads created by the native invocation interface (rather than by Java threads) don't have that sentinel, so a search for it returns null. Therefore, in the rare cases where we have to do a stack walk, we must check for both `NEW_THREAD_BINDINGS` (the sentinel) and `null`. We weren't doing that, we were only checking for null.

-------------

Commit messages:
 - JDK-8319120: Unbound ScopedValue.get() throws the wrong exception

Changes: https://git.openjdk.org/jdk/pull/16422/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16422&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319120
  Stats: 43 lines in 2 files changed: 38 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16422.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16422/head:pull/16422

PR: https://git.openjdk.org/jdk/pull/16422

From alanb at openjdk.org  Mon Oct 30 16:17:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 30 Oct 2023 16:17:32 GMT
Subject: RFR: JDK-8319120: Unbound ScopedValue.get() throws the wrong
 exception
In-Reply-To: 
References: 
Message-ID: 

On Mon, 30 Oct 2023 15:57:23 GMT, Andrew Haley  wrote:

> The bug here is a thinko in `ScopedValue.scopedValueBindings()`.
> 
> If the JVM runs out of resources, we throw a `VirtualMachineError`. Running out of resources can happen at almost any time, and can happen while `ScopedValue`'s internal structures are being modified, leaving them in an inconsistent state. We detect when a `VirtualMachineError` happens and walk the stack to find the most-recent set of `ScopedValue` bindings.
> 
> When we crate a new `Thread`, we push a sentinel frame onto the stack that we can find in the case that we threw a `VirtualMachineError`. Threads created by the native invocation interface (rather than by Java threads) don't have that sentinel, so a search for it returns null. Therefore, in the rare cases where we have to do a stack walk, we must check for both `NEW_THREAD_BINDINGS` (the sentinel) and `null`. We weren't doing that, we were only checking for null.

test/jdk/java/lang/ScopedValue/UnboundValueTest.java line 4:

> 2: 
> 3: /*
> 4:  * @test

It might be better to name the test something like UnboundValueAfterOOME or something better, only because it's not a unit test for all unbound value cases.

You'll need to add a copyright header to the test. Also might be useful to add `@bug 8319120`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16422#discussion_r1376484429

From psandoz at openjdk.org  Mon Oct 30 16:24:34 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 30 Oct 2023 16:24:34 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[] [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 30 Oct 2023 13:43:13 GMT, Per Minborg  wrote:

>> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark and intrinsification spy

test/jdk/jdk/incubator/vector/IntrinsicHeapTest.java line 48:

> 46: import static org.testng.Assert.*;
> 47: 
> 48: public class IntrinsicHeapTest {

I don't think we need this test as part of this PR. It's useful ascertain what is intrinsic or not. We can rethink it as part of the following fix if needed to verify the intrinsics work across all the cross product of array types and vector types.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16360#discussion_r1376494655

From psandoz at openjdk.org  Mon Oct 30 16:34:35 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 30 Oct 2023 16:34:35 GMT
Subject: RFR: 8318678: Vector access on heap MemorySegments only works for
 byte[] [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 30 Oct 2023 13:43:13 GMT, Per Minborg  wrote:

>> This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark and intrinsification spy

Looks good. Please remove `IntrinsicHeapTest` and let's follow up in another issue/PR to fix the mismatched heap access not being intrinsic.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16360#pullrequestreview-1704600236

From aph at openjdk.org  Mon Oct 30 17:16:54 2023
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 30 Oct 2023 17:16:54 GMT
Subject: RFR: JDK-8319120: Unbound ScopedValue.get() throws the wrong
 exception [v2]
In-Reply-To: 
References: 
Message-ID: <1t8usU03GkKm23YwTWcB1pbl-J6lv4JisueZcjv-Gdc=.4df3e979-05a2-42b9-953a-d3db48aa9a99@github.com>

> The bug here is a thinko in `ScopedValue.scopedValueBindings()`.
> 
> If the JVM runs out of resources, we throw a `VirtualMachineError`. Running out of resources can happen at almost any time, and can happen while `ScopedValue`'s internal structures are being modified, leaving them in an inconsistent state. We detect when a `VirtualMachineError` happens and walk the stack to find the most-recent set of `ScopedValue` bindings.
> 
> When we crate a new `Thread`, we push a sentinel frame onto the stack that we can find in the case that we threw a `VirtualMachineError`. Threads created by the native invocation interface (rather than by Java threads) don't have that sentinel, so a search for it returns null. Therefore, in the rare cases where we have to do a stack walk, we must check for both `NEW_THREAD_BINDINGS` (the sentinel) and `null`. We weren't doing that, we were only checking for null.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16422/files
  - new: https://git.openjdk.org/jdk/pull/16422/files/df22ec86..30dca390

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16422&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16422&range=00-01

  Stats: 96 lines in 2 files changed: 60 ins; 36 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16422.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16422/head:pull/16422

PR: https://git.openjdk.org/jdk/pull/16422

From me at tylerkindy.com  Mon Oct 30 17:38:45 2023
From: me at tylerkindy.com (Tyler Kindy)
Date: Mon, 30 Oct 2023 13:38:45 -0400
Subject: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)
In-Reply-To: 
References: 
Message-ID: <14E6FE7A-F8E0-4058-8C1A-B24C833CFD87@tylerkindy.com>

An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Mon Oct 30 17:48:48 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 17:48:48 GMT
Subject: RFR: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test [v9]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which brings  the DataDescriptorSignatureMissing test back to life.
> 
> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` 
> 
> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically.

Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:

 - Describe the structure of Data Descriptors using an example
 - Extend the comment of `makeZipWithSignaturelessDescriptor` with some background info on (signature-less) data descriptors, for the benefit of future maintainers.
 - Convert test from testng to junit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12959/files
  - new: https://git.openjdk.org/jdk/pull/12959/files/de80380f..4a541ffb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12959&range=07-08

  Stats: 43 lines in 1 file changed: 34 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12959/head:pull/12959

PR: https://git.openjdk.org/jdk/pull/12959

From duke at openjdk.org  Mon Oct 30 17:48:52 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 17:48:52 GMT
Subject: RFR: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test [v8]
In-Reply-To: 
References: 
 <--iBU8TPNfvfxtOg2suRlEq1wFf55iFZCE_4N9hw9Ww=.52d201f9-89dc-441b-a260-53d5a8f49ef4@github.com>
 
Message-ID: 

On Mon, 30 Oct 2023 15:02:57 GMT, Lance Andersen  wrote:

> Another question, is the zip that is generated by this test readable by other zip tools such as info-zip, Apache Common-compress, winzip?

- info-zip: Does not support unzipping from a zip,  so uses the CEN instead of the data descriptor.
- Apache commons-compress, reads the signature-less ZIP just fine.
- winzip: I do not currently have easy access to Windows, so can't test this. But I would assume it also uses the CEN when unzipping

> test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 3:
> 
>> 1: /*
>> 2:  * Copyright 2012 Google, Inc.  All Rights Reserved.
>> 3:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> I am not sure the copyright can be updated this way @irisclark, could you provide guidance

This way of updating the copyright was suggested by @jaikiran in the March 10th comment above. Would be nice to get this clarified, yes.

> test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 34:
> 
>> 32:  * without data descriptors was found.
>> 33:  * @run testng DataDescriptorSignatureMissing
>> 34:  */
> 
> Can we convert this please to use junit

Converted to junit as suggested.

> test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 76:
> 
>> 74:     /**
>> 75:      * Produce a ZIP file where the first entry has a signature-less data descriptor
>> 76:      */
> 
> I think it would be useful to show the  what the internal zip representation of the LOC and CEN looks like to make it clear what a signature-less data descriptor is meant to be for future maintainers

Added a comment including some structural examples. (I personally feel it maybe ended up a bit excessive)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12959#issuecomment-1785744562
PR Review Comment: https://git.openjdk.org/jdk/pull/12959#discussion_r1376602288
PR Review Comment: https://git.openjdk.org/jdk/pull/12959#discussion_r1376602596
PR Review Comment: https://git.openjdk.org/jdk/pull/12959#discussion_r1376603460

From bpb at openjdk.org  Mon Oct 30 17:55:47 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Oct 2023 17:55:47 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory [v3]
In-Reply-To: 
References: 
Message-ID: 

> Change test to use `RandomFactory` instead of `new Random()` and convert it to JUnit 5.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8313621: Initialize NUM_RANDOM_TESTS more clearly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16130/files
  - new: https://git.openjdk.org/jdk/pull/16130/files/3f4fc63d..b6e22fca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16130&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16130&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16130/head:pull/16130

PR: https://git.openjdk.org/jdk/pull/16130

From bpb at openjdk.org  Mon Oct 30 17:55:51 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Oct 2023 17:55:51 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 30 Oct 2023 13:57:05 GMT, Raffaello Giulietti  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8313621: assertTrue -> assertEquals
>
> test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal.java line 65:
> 
>> 63: /**
>> 64:  * @test
>> 65:  * @bug 7032154
> 
> Suggestion:
> 
>  * @bug 7032154 8313621

Not adding issue ID as this is a `noreg-self` issue.

> test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal.java line 78:
> 
>> 76:  */
>> 77: public class TestFloatingDecimal {
>> 78:     private static final int NUM_RANDOM_TESTS = 100000;
> 
> Suggestion:
> 
>     private static final int NUM_RANDOM_TESTS = 100_000;

So changed in b6e22fca1f9c992c2d92d89a63898d71495d5a4c.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16130#discussion_r1376610276
PR Review Comment: https://git.openjdk.org/jdk/pull/16130#discussion_r1376608725

From rgiulietti at openjdk.org  Mon Oct 30 17:59:32 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 30 Oct 2023 17:59:32 GMT
Subject: RFR: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 30 Oct 2023 17:55:47 GMT, Brian Burkhalter  wrote:

>> Change test to use `RandomFactory` instead of `new Random()` and convert it to JUnit 5.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313621: Initialize NUM_RANDOM_TESTS more clearly

Marked as reviewed by rgiulietti (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16130#pullrequestreview-1704772673

From duke at openjdk.org  Mon Oct 30 18:00:37 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 30 Oct 2023 18:00:37 GMT
Subject: RFR: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test [v8]
In-Reply-To: 
References: 
 <--iBU8TPNfvfxtOg2suRlEq1wFf55iFZCE_4N9hw9Ww=.52d201f9-89dc-441b-a260-53d5a8f49ef4@github.com>
 
 
Message-ID: 

On Mon, 30 Oct 2023 17:45:28 GMT, Eirik Bjorsnos  wrote:

>> test/jdk/java/util/zip/DataDescriptorSignatureMissing.java line 3:
>> 
>>> 1: /*
>>> 2:  * Copyright 2012 Google, Inc.  All Rights Reserved.
>>> 3:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
>> 
>> I am not sure the copyright can be updated this way @irisclark, could you provide guidance
>
> This way of updating the copyright was suggested by @jaikiran in the March 10th comment above. Would be nice to get this clarified, yes.

There is actually very little left of Martin's code after my rewrite, besides whitespace, some curly braces and a couple of imports. Hardly defensible IP, but then I Am Not a Lawyer :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12959#discussion_r1376616333

From bpb at openjdk.org  Mon Oct 30 18:30:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Oct 2023 18:30:45 GMT
Subject: Integrated: 8313621:
 test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use
 RandomFactory
In-Reply-To: 
References: 
Message-ID: <4QTZ68QypB9XPBPYvSj6-BWovckPjIEDCZRWp3_d2Bo=.d1b8cf92-fc63-492e-adfa-b16122efe0ea@github.com>

On Tue, 10 Oct 2023 23:21:42 GMT, Brian Burkhalter  wrote:

> Change test to use `RandomFactory` instead of `new Random()` and convert it to JUnit 5.

This pull request has now been integrated.

Changeset: 864a876e
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/864a876ebfdf745b0e1f875c3e3668380f2498a7
Stats:     119 lines in 1 file changed: 11 ins; 78 del; 30 mod

8313621: test/jdk/jdk/internal/math/FloatingDecimal/TestFloatingDecimal should use RandomFactory

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/16130

From lmesnik at openjdk.org  Mon Oct 30 18:32:35 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 30 Oct 2023 18:32:35 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: 
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
 
Message-ID: 

On Sun, 29 Oct 2023 14:10:32 GMT, Jaikiran Pai  wrote:

>> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
>> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 
>> 
>> A few tests start failing.
>> 
>> The test
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
>> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.
>> 
>> The test
>> java/lang/Thread/virtual/ThreadAPI.java
>> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.
>> 
>> Test 
>> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.
>> 
>> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.
>
> Hello Leonid, in order to understand what exactly we are trying to solve here, I ran a few tests to see how things work without the changes being proposed in this PR. Here's my findings.
> 
> A bit of background first. When jtreg runs, either in agent mode or othervm mode, it creates a specific thread within which the actual test code runs. In either of these modes, it uses a custom jtreg specific `ThreadGroup` instance for this thread which is running the test code. This instance of `ThreadGroup` has specific overridden implementation of the `public void uncaughtException(Thread t, Throwable e)` API which keeps track of uncaught exception that might have been thrown by any threads that could have been spawned by the test. After `start()`ing the thread which runs the test code, the jtreg framework then waits for that thread to complete and once completed (either exceptionally or normally), jtreg framework then queries a state on the custom `ThreadGroup` instance to see if any uncaught exception(s) were received during the lifetime of this thread which ran that test. If it finds any, then it marks the test as failed and reports such a failure appropriately in the test re
 port. As noted, this applies for both the agent mode and other vm mode. Some important aspects of this implementation is that:
> 
> - The custom `ThreadGroup` which has the overridden implementation of the `uncaughtException(Thread t, Throwable e)` method doesn't interfere with the JVM level default exception handler.
> 
> - After the thread which ran the test code completes, the decision on whether to fail or pass a test is taken by checking the custom `ThreadGroup`'s state. Once this decision is done, the decision is immediately reported in relevant ways and the test status is marked (i.e. finalized) at this point.
> 
> - If this was running in agent vm mode, the agent vm mode continues to operate and isn't terminated and thus is available for subsequent tests. This point I think is important to remember for reasons that will be noted later in this comment.
> 
> Now coming to the part where in https://bugs.openjdk.org/browse/JDK-8303703 we introduced a way where jtreg instead of creating a platform thread (backed by its custom implementation of the `ThreadGroup`) to run the test code, now checks the presence of a `ThreadFactory` and if present, lets it create a `Thread` which runs this test code. In the JDK repo, we have an implementation of a `ThreadFactory` which creates a virtual thread instead of platform...

@jaikiran, your analysis is correct. 
@jaikiran , @dholmes-ora  The jtreg is going to be fixed to handle all uncaught exceptions. See PR: https://github.com/openjdk/jtreg/pull/172
The problem might happens not only with test thread factory, but for any virtual threads and might be for system threads.  It is more generic solution and might take a lot of time to be correctly implemented. So this pr is just temporary fix until jtreg is updated.  I could withdraw this PR, but not sure what are the risks/issues if I integrate it. We are going just to have a ugly error reporting for the uncaught threads when test thread factory is used  or missed something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1785813862

From almatvee at openjdk.org  Mon Oct 30 19:48:46 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 30 Oct 2023 19:48:46 GMT
Subject: RFR: 8310933: Copying from runtime image to application image should
 not follow symlinks
Message-ID: 

- Added LinkOption.NOFOLLOW_LINKS when copying pre-define runtime image.
- Added test to cover this change.
- Cleanup RuntimeImageTest.java by removing unused imports and removed incubator from jpackage module name.

-------------

Commit messages:
 - 8310933: Copying from runtime image to application image should not follow symlinks

Changes: https://git.openjdk.org/jdk/pull/16426/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310933
  Stats: 128 lines in 4 files changed: 114 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16426.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16426/head:pull/16426

PR: https://git.openjdk.org/jdk/pull/16426

From asemenyuk at openjdk.org  Mon Oct 30 19:56:31 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 30 Oct 2023 19:56:31 GMT
Subject: RFR: 8310933: Copying from runtime image to application image
 should not follow symlinks
In-Reply-To: 
References: 
Message-ID: 

On Mon, 30 Oct 2023 19:43:32 GMT, Alexander Matveev  wrote:

> - Added LinkOption.NOFOLLOW_LINKS when copying pre-define runtime image.
> - Added test to cover this change.
> - Cleanup RuntimeImageTest.java by removing unused imports and removed incubator from jpackage module name.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16426#pullrequestreview-1704960747

From lancea at openjdk.org  Mon Oct 30 19:56:35 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 30 Oct 2023 19:56:35 GMT
Subject: RFR: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 30 Oct 2023 17:48:48 GMT, Eirik Bjorsnos  wrote:

>> Please review this PR which brings  the DataDescriptorSignatureMissing test back to life.
>> 
>> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` 
>> 
>> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically.
>
> Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Describe the structure of Data Descriptors using an example
>  - Extend the comment of `makeZipWithSignaturelessDescriptor` with some background info on (signature-less) data descriptors, for the benefit of future maintainers.
>  - Convert test from testng to junit

Thinking some more about this, I would like to see us keep the Zip generated by python, store it in a byte array (or equivalent) as it also validate that we can still process the zip given this was the original test and the zip is being generated by a 3rd party tool.

This would be an additional test along with your proposed enhancements

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12959#issuecomment-1785936716

From almatvee at openjdk.org  Mon Oct 30 21:12:43 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 30 Oct 2023 21:12:43 GMT
Subject: Integrated: 8310933: Copying from runtime image to application image
 should not follow symlinks
In-Reply-To: 
References: 
Message-ID: 

On Mon, 30 Oct 2023 19:43:32 GMT, Alexander Matveev  wrote:

> - Added LinkOption.NOFOLLOW_LINKS when copying pre-define runtime image.
> - Added test to cover this change.
> - Cleanup RuntimeImageTest.java by removing unused imports and removed incubator from jpackage module name.

This pull request has now been integrated.

Changeset: 1ca2cfaf
Author:    Alexander Matveev 
URL:       https://git.openjdk.org/jdk/commit/1ca2cfafdd906851b923be69852ccf9a3bb4db35
Stats:     128 lines in 4 files changed: 114 ins; 9 del; 5 mod

8310933: Copying from runtime image to application image should not follow symlinks

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/16426

From viktor.klang at oracle.com  Mon Oct 30 21:59:48 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 30 Oct 2023 21:59:48 +0000
Subject: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)
In-Reply-To: <14E6FE7A-F8E0-4058-8C1A-B24C833CFD87@tylerkindy.com>
References: 
 <14E6FE7A-F8E0-4058-8C1A-B24C833CFD87@tylerkindy.com>
Message-ID: 

That's also a good point, and I've heard from multiple sources that sometimes you want to make sure that you only have a single element left at the end, and otherwise throw an exception.

Fortunately it is possible to do something to the effect of:

// Proof of concept only
public static  Collector singleton() {
    class State { T value; boolean hasValue; }
    return Collector.of(
        State::new,
        (state, e) -> {
            if (state.hasValue)
                throw new IllegalStateException("Stream has more than one element!");

            state.hasValue = true;
            state.value = e;
        },
        (left, right) -> {
            if (left.hasValue && right.hasValue)
                throw new IllegalStateException("Stream has more than one element!");
            else if (left.hasValue)
                return left;
            else
                return right;
        },
        (state) -> {
            if (!state.hasValue)
                throw new IllegalStateException("Stream has less than one element!");
            else
                return state.value;
        });
}

Which means that you could write things like:

var neatlyFolded = stream.gather(fold(?)).collect(singleton());

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Tyler Kindy 
Sent: Monday, 30 October 2023 18:38
To: Viktor Klang 
Cc: core-libs-dev at openjdk.org 
Subject: Re: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)

Hi Viktor,

Thanks for the response! I see what you mean, it?s a good point that single-element streams are just as valid as streams with other numbers of elements.

The weird part for me, though, is getting the folded result out of the stream at the end (which, while not always, I believe will be the most common thing to want to do after `fold`). The obvious way, which you used in your presentation, is `findAny`. Since the stream could be empty, it makes sense that `findAny` returns an `Optional`, but with `fold` we know that the stream will have exactly one element in it.

Of course, this API is totally serviceable. You can use `Optional::orElseThrow` on the result of `findAny` to communicate your intent that you expect there to be an element. But that feels a bit roundabout to me; I feel that a cleaner API would be to get the folded result out directly, like how `Collector` works.

To your point, implementing `fold` as a Gatherer doesn?t mean we can never have a terminal `fold`. And having `fold` in any way at all is great; that?s one feature of Streams I commonly find myself wanting when writing code (the other is windowing, which I think you?ve covered the need for well; no notes on those ?).

But it does make me wish that `Collector` was also flexible enough to implement `fold`. Maybe a topic for future work. ?

Thanks again,
Tyler

On Oct 30, 2023, at 10:39?AM, Viktor Klang  wrote:

?
Hi Tyler,

Thank you for the kind words -- they are much appreciated. And you have a very good question indeed!

My thinking behind making fold a Gatherer is that I think that it is strictly more powerful than "only" having it as a collector (It wouldn't be able to be a Collector since you'd need a combiner for it, but also being able to compose it with other operations, choosing the output type at a later stage in the process, and so forth).

Also, if you think about it -- single-element Streams are just as valid as empty Streams, N-sized Streams, or even unbounded Streams, and conceptually, there's no difference between the following two Streams:

var a = Stream.of("1234")
var b = Stream.of(1,2,3,4).gather(fold(() -> "", (str, next) -> str + next))

So that was my thinking?allow developers to stay within Stream processing for as long as they want, and choose the terminal operation when they need to break out from the Stream.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Tyler Kindy 
Sent: Monday, 30 October 2023 12:14
To: Viktor Klang 
Cc: core-libs-dev at openjdk.org 
Subject: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)

?
?Thanks for the JEP and your talk, Viktor! I think `Stream::gather` will be super useful in my day-to-day as a Java developer.

I?m curious why `fold` is being implemented with gatherers. I recognize `Gatherer` is designed to support intermediate operations, but `fold` feels inherently like a terminal operation to me since it, like `reduce` or `collect`, consumes all the elements in the stream and produces a single result.

Is there a technical limitation to making `fold` a terminal operation? For example, does `Collector` inherently presume parallelization in a way that `Gatherer` does not?

Or is the idea mainly to demonstrate the power of gatherers, and we could also make `fold` a terminal operation with the current `Stream` API?

Thank you!
Tyler Kindy

On Oct 27, 2023, at 9:50?AM, Viktor Klang  wrote:

Greetings,

As you may have already seen, Stream Gatherers is now a Preview JEP with Candidate status

Work-in-progress (interfaces, implementation, tests, benches, and documentation) for JEP-461 is currently available here.

While the design has held up well, there are some important improvements made since the original design document was written.

Notable changes (without any particular order):

  *   Stream::gather() now has a default implementation.

  *   Gatherer::supplier() was renamed to Gatherer::initializer() to better reflect intent.

  *   Gatherer.Sink was renamed to Gatherer.Downstream to better signal what it represents.

  *   Gatherer::collect(Collector) and its companion type Gatherer.ThenCollector was dropped due to compatibility concerns with existing code which operates on Collector.

  *
Gatherer.Characteristics have been eliminated and superseded by having default values that are used as sentinels.
 (discussed further down the list)
This is important because with the Characteristics-model keeping alignment between Characteristics and actual implementation proved brittle, and under composition of Gatherers computing the union was inefficient and mostly lead to an empty set in the end.

  *   Gatherer.defaultInitializer(), Gatherer.defaultCombiner(), and Gatherer.defaultFinisher() were added as static methods?these are the sentinels used to elide calling the initializer, to elide calling the combiner (avoid parallelization), and to elide calling the finisher, respectively.

  *   Gatherer::initializer(), Gatherer::combiner(), and Gatherer::finisher() default implementations return the respective sentinels.

  *   A subtype of Integrator named Greedy was added, together with a factory method to guide lambda-to-nominal-type conversion. This allows creators of Gatherers to signal that an Integrator will never initiate a short-circuit (but may relay one from downstream), and that is available during evaluation to determine if the operation can short-circuit or not.

  *   Factories for creating anonymous Gatherers were expanded upon to include Gatherer.of() and Gatherer.ofSequential() with different sets of parameters, primarily to make it more ergonomical and easier to read and write the code using those factories.

  *   A curated set of initial built-in Gatherers is located in java.util.stream.Gatherers

I recently presented Gatherers at Devoxx, which I'd recommend watching for an introduction to the feature.

Teaching old Streams new tricks By Viktor Klang
Have you ever wanted to perform an operation on a java.util.stream.Stream only to find that the existing set of operations didn't provide what you needed?forcing you to break out early from the Stream and perform the logic outside of it? As a matter of fact, java.util.stream was the first JDK API designed with lambdas in mind and was ...
www.youtube.com
??????

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From abimpoudis at openjdk.org  Mon Oct 30 22:27:18 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 30 Oct 2023 22:27:18 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v27]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <4L-TUvaw9p-MEi5GpE8XI1XhCOcIVdtPGn5kLdnUU3U=.d635720d-68a6-4848-8aa6-61ac42fbc6e3@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Merge branch 'master' into primitive-patterns
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java
 - Add tests for new data types in switch statements
 - Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests
 - Fix SwitchBootstraps for pattern matching over longs
 - Merge branch 'master' into primitive-patterns
 - Improve javadoc of ExactConversionsSupport
   
   Co-authored-by: Raffaello Giulietti 
 - Adjust javadoc on ExactConversionsSupport
 - Merge branch 'master' into primitive-patterns
 - Address review
   
   - Add comments
   - Rename exactness methods
   - Use convenience methods from TypeTag for checkUnconditionallyExactPrimitives in Types
   - Port isStrictSubRangeOf to Wrapper and use it for unconditionalExactnessCheck in SwitchBootstraps
 - Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
 - ... and 23 more: https://git.openjdk.org/jdk/compare/1ca2cfaf...b437373b

-------------

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=26
  Stats: 3055 lines in 40 files changed: 2799 ins; 111 del; 145 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From forax at univ-mlv.fr  Mon Oct 30 22:39:31 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 30 Oct 2023 23:39:31 +0100 (CET)
Subject: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)
In-Reply-To: 
References: 
 <14E6FE7A-F8E0-4058-8C1A-B24C833CFD87@tylerkindy.com>
 
Message-ID: <218519414.39489013.1698705571799.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" 
> To: "Tyler Kindy" 
> Cc: "core-libs-dev" 
> Sent: Monday, October 30, 2023 10:59:48 PM
> Subject: Re: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)

> That's also a good point, and I've heard from multiple sources that sometimes
> you want to make sure that you only have a single element left at the end, and
> otherwise throw an exception.

Hello, 

> Fortunately it is possible to do something to the effect of:

> // Proof of concept only
> public static  Collector singleton() {
> class State { T value; boolean hasValue; }
> return Collector.of(
> State::new,
> (state, e) -> {
> if (state.hasValue)
> throw new IllegalStateException("Stream has more than one element!");

> state.hasValue = true;
> state.value = e;
> },
> (left, right) -> {
> if (left.hasValue && right.hasValue)
> throw new IllegalStateException("Stream has more than one element!");
> else if (left.hasValue)
> return left;
> else
> return right;
> },
> (state) -> {
> if (!state.hasValue)
> throw new IllegalStateException("Stream has less than one element!");
> else
> return state.value;
> });
> }

> Which means that you could write things like:

> var neatlyFolded = stream.gather(fold(?)).collect(singleton());

I will ask for a step further and add an overload to collect that takes a Gatherer and calls gather(gatherer).collect(Collectors.singleton()) so we can directly write 
var neatlyFolded = stream.collect(fold(...)); 

As a user, I see value in using the more powerful Gatherer API like a collector without having to think too much. 

> Cheers,
> ?

regards, 
R?mi 

> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

> From: Tyler Kindy 
> Sent: Monday, 30 October 2023 18:38
> To: Viktor Klang 
> Cc: core-libs-dev at openjdk.org 
> Subject: Re: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)
> Hi Viktor,

> Thanks for the response! I see what you mean, it?s a good point that
> single-element streams are just as valid as streams with other numbers of
> elements.

> The weird part for me, though, is getting the folded result out of the stream at
> the end (which, while not always, I believe will be the most common thing to
> want to do after `fold`). The obvious way, which you used in your presentation,
> is `findAny`. Since the stream could be empty, it makes sense that `findAny`
> returns an `Optional`, but with `fold` we know that the stream will have
> exactly one element in it.

> Of course, this API is totally serviceable. You can use `Optional::orElseThrow`
> on the result of `findAny` to communicate your intent that you expect there to
> be an element. But that feels a bit roundabout to me; I feel that a cleaner API
> would be to get the folded result out directly, like how `Collector` works.

> To your point, implementing `fold` as a Gatherer doesn?t mean we can never have
> a terminal `fold`. And having `fold` in any way at all is great; that?s one
> feature of Streams I commonly find myself wanting when writing code (the other
> is windowing, which I think you?ve covered the need for well; no notes on those
> \uD83D\uDE04).

> But it does make me wish that `Collector` was also flexible enough to implement
> `fold`. Maybe a topic for future work. \uD83D\uDE04

> Thanks again,
> Tyler

>> On Oct 30, 2023, at 10:39 AM, Viktor Klang  wrote:

>> Hi Tyler,

>> Thank you for the kind words -- they are much appreciated. And you have a very
>> good question indeed!

>> My thinking behind making fold a Gatherer is that I think that it is strictly
>> more powerful than "only" having it as a collector (It wouldn't be able to be a
>> Collector since you'd need a combiner for it, but also being able to compose it
>> with other operations, choosing the output type at a later stage in the
>> process, and so forth).

>> Also, if you think about it -- single-element Streams are just as valid as empty
>> Streams, N-sized Streams, or even unbounded Streams, and conceptually, there's
>> no difference between the following two Streams:

>> var a = Stream.of("1234")
>> var b = Stream.of(1,2,3,4).gather(fold(() -> "", (str, next) -> str + next))

>> So that was my thinking?allow developers to stay within Stream processing for as
>> long as they want, and choose the terminal operation when they need to break
>> out from the Stream.

>> Cheers,
>> ?

>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

>> From: Tyler Kindy 
>> Sent: Monday, 30 October 2023 12:14
>> To: Viktor Klang 
>> Cc: core-libs-dev at openjdk.org 
>> Subject: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)
>> Thanks for the JEP and your talk, Viktor! I think `Stream::gather` will be super
>> useful in my day-to-day as a Java developer.

>> I?m curious why ` fold` is being implemented with gatherers. I recognize
>> `Gatherer` is designed to support intermediate operations, but `fold` feels
>> inherently like a terminal operation to me since it, like `reduce` or
>> `collect`, consumes all the elements in the stream and produces a single
>> result.

>> Is there a technical limitation to making `fold` a terminal operation? For
>> example, does `Collector` inherently presume parallelization in a way that
>> `Gatherer` does not?

>> Or is the idea mainly to demonstrate the power of gatherers, and we could also
>> make `fold` a terminal operation with the current `Stream` API?

>> Thank you!
>> Tyler Kindy

>>> On Oct 27, 2023, at 9:50 AM, Viktor Klang  wrote:

>>> Greetings,

>>> As you may have already seen, Stream Gatherers is now a [
>>> https://openjdk.org/jeps/461 | Preview
>>>  JEP with Candidate status ]

>>> Work-in-progress (interfaces, implementation, tests, benches, and documentation)
>>> for JEP-461 is currently available [
>>> https://urldefense.com/v3/__https://github.com/viktorklang-ora/jdk/tree/gatherer__;!!ACWV5N9M2RV99hQ!Lz2sC02xW35XpuwoaqBvD_iR80Xrzkbj-60oOKuQklUOm8e69-O3WC9N93leBFbMkFmULJmsat9k1dmt$
>>> | here ] .

>>> While [ https://cr.openjdk.org/~vklang/Gatherers.html | the design ] has held up
>>> well, there are some important improvements made since the original design
>>> document was written.

>>> Notable changes (without any particular order):

>>>     * Stream::gather() now has a default implementation.
>>>    * Gatherer ::supplier() was renamed to Gatherer::initializer() to better reflect
>>>     intent.
>>>    * Gatherer.Sink was renamed to Gatherer.Downstream to better signal what
>>>     it represents.
>>>    * Gatherer::collect(Collector) and its companion type Gatherer.ThenCollector was
>>>    dropped due to compatibility concerns with existing code which operates on
>>>     Collector .
>>>     *
>>> Gatherer.Characteristics have been eliminated and superseded by having default
>>> values that are used as sentinels.
>>> (discussed further down the list)
>>> This is important because with the Characteristics-model keeping alignment
>>> between Characteristics and actual implementation proved brittle, and under
>>> composition of Gatherers computing the union was inefficient and mostly lead to
>>> an empty set in the end.

>>>    * Gatherer.defaultInitializer() , Gatherer.defaultCombiner() , and
>>>    Gatherer.defaultFinisher() were added as static methods?these are the sentinels
>>>    used to elide calling the initializer, to elide calling the combiner (avoid
>>>     parallelization), and to elide calling the finisher, respectively.
>>>    * Gatherer::initializer() , Gatherer::combiner() , and Gatherer::finisher()
>>>     default implementations return the respective sentinels.
>>>    * A subtype of Integrator named Greedy was added, together with a factory method
>>>    to guide lambda-to-nominal-type conversion. This allows creators of Gatherers
>>>    to signal that an Integrator will never initiate a short-circuit (but may relay
>>>    one from downstream), and that is available during evaluation to determine if
>>>     the operation can short-circuit or not.

>>>    * Factories for creating anonymous Gatherers were expanded upon to include
>>>    Gatherer.of() and Gatherer.ofSequential() with different sets of parameters,
>>>    primarily to make it more ergonomical and easier to read and write the code
>>>     using those factories.

>>>    * A curated set of initial built-in Gatherers is located in
>>>     java.util.stream.Gatherers
>>> I recently presented [
>>> https://urldefense.com/v3/__https://www.youtube.com/watch?v=8fMFa6OqlY8__;!!ACWV5N9M2RV99hQ!Lz2sC02xW35XpuwoaqBvD_iR80Xrzkbj-60oOKuQklUOm8e69-O3WC9N93leBFbMkFmULJmsam2MP-_S$
>>> | Gatherers
>>>  at Devoxx ] , which I'd recommend watching for an introduction to the feature.


>>> [
>>> https://urldefense.com/v3/__https://www.youtube.com/watch?v=8fMFa6OqlY8__;!!ACWV5N9M2RV99hQ!Lz2sC02xW35XpuwoaqBvD_iR80Xrzkbj-60oOKuQklUOm8e69-O3WC9N93leBFbMkFmULJmsam2MP-_S$
>>> |  ]

>>> [
>>> https://urldefense.com/v3/__https://www.youtube.com/watch?v=8fMFa6OqlY8__;!!ACWV5N9M2RV99hQ!Lz2sC02xW35XpuwoaqBvD_iR80Xrzkbj-60oOKuQklUOm8e69-O3WC9N93leBFbMkFmULJmsam2MP-_S$
>>> | Teaching
>>>  old Streams new tricks By Viktor Klang ]
>>> Have you ever wanted to perform an operation on a java.util.stream.Stream only
>>> to find that the existing set of operations didn't provide what you
>>> needed?forcing you to break out early from the Stream and perform the logic
>>> outside of it? As a matter of fact, java.util.stream was the first JDK API
>>> designed with lambdas in mind and was ...
>>> [
>>> https://urldefense.com/v3/__http://www.youtube.com/__;!!ACWV5N9M2RV99hQ!Lz2sC02xW35XpuwoaqBvD_iR80Xrzkbj-60oOKuQklUOm8e69-O3WC9N93leBFbMkFmULJmsalMQI96j$
>>> | www.youtube.com ]

>>> Cheers,
>>> ?

>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dholmes at openjdk.org  Mon Oct 30 22:56:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 30 Oct 2023 22:56:31 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: 
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
 
 
Message-ID: <0EcMjUEFedq-qGfu52qTJ_5X6jde-BD4Ej9NWvsNXfs=.30d2ea1a-7138-4118-aa1f-9b9c1367f3dc@github.com>

On Mon, 30 Oct 2023 18:29:30 GMT, Leonid Mesnik  wrote:

>> Hello Leonid, in order to understand what exactly we are trying to solve here, I ran a few tests to see how things work without the changes being proposed in this PR. Here's my findings.
>> 
>> A bit of background first. When jtreg runs, either in agent mode or othervm mode, it creates a specific thread within which the actual test code runs. In either of these modes, it uses a custom jtreg specific `ThreadGroup` instance for this thread which is running the test code. This instance of `ThreadGroup` has specific overridden implementation of the `public void uncaughtException(Thread t, Throwable e)` API which keeps track of uncaught exception that might have been thrown by any threads that could have been spawned by the test. After `start()`ing the thread which runs the test code, the jtreg framework then waits for that thread to complete and once completed (either exceptionally or normally), jtreg framework then queries a state on the custom `ThreadGroup` instance to see if any uncaught exception(s) were received during the lifetime of this thread which ran that test. If it finds any, then it marks the test as failed and reports such a failure appropriately in the test r
 eport. As noted, this applies for both the agent mode and other vm mode. Some important aspects of this implementation is that:
>> 
>> - The custom `ThreadGroup` which has the overridden implementation of the `uncaughtException(Thread t, Throwable e)` method doesn't interfere with the JVM level default exception handler.
>> 
>> - After the thread which ran the test code completes, the decision on whether to fail or pass a test is taken by checking the custom `ThreadGroup`'s state. Once this decision is done, the decision is immediately reported in relevant ways and the test status is marked (i.e. finalized) at this point.
>> 
>> - If this was running in agent vm mode, the agent vm mode continues to operate and isn't terminated and thus is available for subsequent tests. This point I think is important to remember for reasons that will be noted later in this comment.
>> 
>> Now coming to the part where in https://bugs.openjdk.org/browse/JDK-8303703 we introduced a way where jtreg instead of creating a platform thread (backed by its custom implementation of the `ThreadGroup`) to run the test code, now checks the presence of a `ThreadFactory` and if present, lets it create a `Thread` which runs this test code. In the JDK repo, we have an implementation of a `ThreadFactory` which creates a virtual thre...
>
> @jaikiran, your analysis is correct. 
> @jaikiran , @dholmes-ora  The jtreg is going to be fixed to handle all uncaught exceptions. See PR: https://github.com/openjdk/jtreg/pull/172
> The problem might happens not only with test thread factory, but for any virtual threads and might be for system threads.  It is more generic solution and might take a lot of time to be correctly implemented. So this pr is just temporary fix until jtreg is updated.  I could withdraw this PR, but not sure what are the risks/issues if I integrate it. We are going just to have a ugly error reporting for the uncaught threads when test thread factory is used  or missed something?

@lmesnik  Using `System.exit` is just wrong - we don't use that in JTREG tests at all. I would suggest just ProblemListing problematic tests that won't work as expected with virtual threads, until jtreg addresses this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1786171041

From myano at openjdk.org  Tue Oct 31 00:17:32 2023
From: myano at openjdk.org (Masanori Yano)
Date: Tue, 31 Oct 2023 00:17:32 GMT
Subject: RFR: 8315004: Runtime.halt() debug logging
In-Reply-To: <9dyKdOjb2grEjFxBeApwJ0NeP8vziPGEQrvTpf4kY0M=.9b642538-1142-491e-8fb3-d3c2382851c7@github.com>
References: 
 
 <9dyKdOjb2grEjFxBeApwJ0NeP8vziPGEQrvTpf4kY0M=.9b642538-1142-491e-8fb3-d3c2382851c7@github.com>
Message-ID: 

On Fri, 1 Sep 2023 08:29:41 GMT, Alan Bateman  wrote:

>> I think you may have missed the comment in the JBS issue. Logging means running potentially arbitrary code, doing this at Runtime.halt time is problematic. I thought the conclusion from the work on Runtime.exit was not to log in Runtime.halt?
>
>> @AlanBateman Sorry for missing your comment on JBS. I can't find any discussion of the need for logs in Runtime.halt in JDK-8301627, so I'm not sure if it was intentional that no logging output was added to Runtime.halt.
>> However, if Runtime.halt is overlooked without discussion, I think it should be added after considering the need.
>> I think it's the same problem as Runtime.exit when it comes to executing arbitrary code.
>> Are there any issues specific to Runtime.halt?
> 
> The purpose of the halt method is to terminate immediately, it doesn't initiate the shutdown sequence. My recollection of the System.exit logging is that it was deliberate to not change the halt method. Changing halt to log means it would not terminate immediately. Also I think there were concerns with logging libraries that needed the shutdown hook to execute in order to fush/close logs. @RogerRiggs or @stuart-marks may be able to say more about this.

@AlanBateman @RogerRiggs Could you comment on the above?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1786240078

From xgong at openjdk.org  Tue Oct 31 00:56:34 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 31 Oct 2023 00:56:34 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v2]
In-Reply-To: <29iCeYY3SJrGjmd5gDsufdutIdfAcwYEPYOEo59G3IE=.73c69a72-1b19-4fd9-928b-a246f642e0ed@github.com>
References: 
 
 
 
 <29iCeYY3SJrGjmd5gDsufdutIdfAcwYEPYOEo59G3IE=.73c69a72-1b19-4fd9-928b-a246f642e0ed@github.com>
Message-ID: 

On Sun, 29 Oct 2023 22:11:31 GMT, Jatin Bhateja  wrote:

> I think for the time being its better to align masked sub-word gather implementation with non-sub-word ones i.e. support intrinsfication only for predicated targets. Respective backends may then choose to either emit a predicated loop like the one which this patch does OR directly emit a predicated instruction if target support it. WDYT?

Agree!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1376938922

From xgong at openjdk.org  Tue Oct 31 01:04:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 31 Oct 2023 01:04:30 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Sun, 29 Oct 2023 22:23:09 GMT, Jatin Bhateja  wrote:

> Due to lane size differences b/w sub-word and integer it may never be possible to have compatible species.

That's true. So maybe we could just 1) make sure the index array is inside of the boundary (i.e. the length is at least the same with the vectors), and 2) generate the index vectors during intrinsification for some architectures that need it (i.e. ARM SVE). For now, since only x86 implement it, maybe the second one is not needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1376942116

From qamai at openjdk.org  Tue Oct 31 01:34:33 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 31 Oct 2023 01:34:33 GMT
Subject: RFR: 8315004: Runtime.halt() debug logging
In-Reply-To: 
References: 
 
 <9dyKdOjb2grEjFxBeApwJ0NeP8vziPGEQrvTpf4kY0M=.9b642538-1142-491e-8fb3-d3c2382851c7@github.com>
 
Message-ID: 

On Tue, 31 Oct 2023 00:14:39 GMT, Masanori Yano  wrote:

>>> @AlanBateman Sorry for missing your comment on JBS. I can't find any discussion of the need for logs in Runtime.halt in JDK-8301627, so I'm not sure if it was intentional that no logging output was added to Runtime.halt.
>>> However, if Runtime.halt is overlooked without discussion, I think it should be added after considering the need.
>>> I think it's the same problem as Runtime.exit when it comes to executing arbitrary code.
>>> Are there any issues specific to Runtime.halt?
>> 
>> The purpose of the halt method is to terminate immediately, it doesn't initiate the shutdown sequence. My recollection of the System.exit logging is that it was deliberate to not change the halt method. Changing halt to log means it would not terminate immediately. Also I think there were concerns with logging libraries that needed the shutdown hook to execute in order to fush/close logs. @RogerRiggs or @stuart-marks may be able to say more about this.
>
> @AlanBateman @RogerRiggs Could you comment on the above?

@masyano Probably in that case a diagnostic flag that defaulted to `false` may be more reasonable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1786294006

From jpai at openjdk.org  Tue Oct 31 05:59:31 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 31 Oct 2023 05:59:31 GMT
Subject: RFR: 8318839: Update test thread factory to catch all exceptions
In-Reply-To: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com>
Message-ID: 

On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik  wrote:

> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526.
> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. 
> 
> A few tests start failing.
> 
> The test
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory.
> 
> The test
> java/lang/Thread/virtual/ThreadAPI.java
> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory.
> 
> Test 
> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler.
> 
> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg.

Hello Leonid,

> So this pr is just temporary fix until jtreg is updated.
> ...
> I could withdraw this PR, but not sure what are the risks/issues if I integrate it. We are going just to have a ugly error reporting for the uncaught threads when test thread factory is used or missed something?

I think there is more than one problem with the proposed approach and those problems outweigh any usefulness this change might bring in.

Specifically, this PR introduces a call to `System.exit()` which terminates a JVM. When that happens, it's not the ugly error reporting which is a problem, but the fact that tests which get abruptly terminated like this will have no way to determine what went wrong. For example, you will see:

> result: Error. Agent communication error: java.io.EOFException; check console log for any additional details
>
>
> test result: Error. Agent communication error: java.io.EOFException; check console log for any additional details

Whether or not there will be any additional logs anywhere is uncertain because jtreg and other infrastructure which does any kind of buffering of logs and other state wouldn't have had a chance to properly report the state/logs. It's almost as if the (remote) JVM has crashed. In fact even genuine failures from the test may not get reported and instead might get replaced by this generic JVM termination reporting.

Furthermore, in its current form the System.exit() gets called when an uncaught exception gets thrown from some thread. When this happens, the test itself might not have completed (unlike in the case of the platform threads, where jtreg just keeps track of the uncaught exception and when the test is finally complete, it uses that state to do the decision of failing or passing the test).

Then there is the case where the JVM level uncaught exception handler is being changed in this proposal. What that means is, when run with a virtual thread, this will now impact tests which (rightly) expect that the default uncaught exception handler would be null. One such example is the `test/jdk/java/util/concurrent/tck/ThreadTest.java` which is being updated in this PR. Not even using `/othervm` in those tests will get them to a state where they can expect the default uncaught exception handler to be null because even in `/othervm` scenarios, this proposed change will have set the default uncaught exception handler.

If we leave out setting the default uncaught exception handler and the call to System.exit() from this PR, then what remains is just the exception logging and stacktrace printing. That part is currently anyway available even without this proposed change, because the "system" `ThreadGroup` does exactly that https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ThreadGroup.java#L696. In fact, if we currently run the tests using this virtual thread factory and then once the tests complete, if we run a search for this error mesage from the "system" ThreaGroup, we should be able to identify all those tests which had a thread throw some uncaught exception.

Given all this, I think this PR isn't introducing anything new that will help us even in the short term.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1786498722

From ccheung at openjdk.org  Tue Oct 31 06:11:50 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 31 Oct 2023 06:11:50 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v7]
In-Reply-To: 
References: 
Message-ID: 

> Please review this changeset for adding support for `--module` (-m) option for CDS.
> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
> 
> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  comments from Ioi and Alan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16016/files
  - new: https://git.openjdk.org/jdk/pull/16016/files/5c2a0e9c..daec9915

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=05-06

  Stats: 45 lines in 5 files changed: 23 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/16016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16016/head:pull/16016

PR: https://git.openjdk.org/jdk/pull/16016

From ccheung at openjdk.org  Tue Oct 31 06:16:38 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 31 Oct 2023 06:16:38 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v6]
In-Reply-To: <_kRxr4CnDC2ouiocb43oqSNVPOI1xeJ4LTRhXwWeeYg=.eef409db-3a40-483d-9e54-9914bb524520@github.com>
References: 
 
 <_kRxr4CnDC2ouiocb43oqSNVPOI1xeJ4LTRhXwWeeYg=.eef409db-3a40-483d-9e54-9914bb524520@github.com>
Message-ID: 

On Fri, 27 Oct 2023 16:28:10 GMT, Ioi Lam  wrote:

>> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Merge master
>>  - skip archiving full module graph is there is an incubator module
>>  - fix typo
>>  - simplify some code in modules.cpp
>>  - comments from Alan and Ioi; add missing @run tag in the test
>>  - Merge branch 'master' into improve-CDS-module-graph
>>  - better way to check if a module is a JDK module
>>  - initial review comments from Ioi
>>  - 8316969: Improve CDS module graph support for --module option
>
> src/hotspot/share/cds/metaspaceShared.cpp line 790:
> 
>> 788:   ArchiveHeapWriter::init();
>> 789:   if (use_full_module_graph()) {
>> 790:     HeapShared::reset_archived_object_states(CHECK);
> 
> This block of code needs to be inside `if (CDSConfig::is_dumping_heap())`

Thanks for catching this. Fixed.
Also moved the `HeapShared::init_for_dumping(CHECK)` inside the "if" block.

> test/hotspot/jtreg/runtime/cds/appcds/jigsaw/module/ModuleOption.java line 107:
> 
>> 105:         oa.shouldHaveExitValue(0)
>> 106:           // module graph won't be archived with an incubator module
>> 107:           .shouldContain("archivedBootLayer not available, disabling full module graph");
> 
> For thoroughness, I think we should also check for this log in heapShared.cpp:
> 
> 
>     if (record->is_full_module_graph() && !CDSConfig::is_loading_full_module_graph()) {
>       if (log_is_enabled(Info, cds, heap)) {
>         ResourceMark rm(THREAD);
>         log_info(cds, heap)("subgraph %s cannot be used because full module graph is disabled",
>                             k->external_name());
>       }
>       return nullptr;
>     }

For this case, the record is null. Per our discussion, I've added another log for the null record case:
 ```
968   if (record == nullptr) {
 969     if (log_is_enabled(Info, cds, heap)) {
 970       ResourceMark rm(THREAD);
 971       log_info(cds, heap)("subgraph %s is not recorded",
 972                           k->external_name());
 973     }

and updated the test accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1377097395
PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1377097436

From ccheung at openjdk.org  Tue Oct 31 06:20:36 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 31 Oct 2023 06:20:36 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 <5lYwJpqhgq2MEJ17xpslna437GsmZFAH5v3FyWRhh-Q=.83077177-f238-4cdb-b65d-06e013b4edaf@github.com>
 
 <6Uy4_u0RQeGKXwUYk8REFcRYlx1AuSgbyQSClrlwFLU=.8c21fcdb-89b4-4bfc-a812-e0bed27d0efe@github.com>
 
Message-ID: 

On Sat, 28 Oct 2023 06:37:00 GMT, Alan Bateman  wrote:

>> The `ArchivedModuleGraph.java` wasn't changed. So if `-m` is not specified, the `archivedModuleGraph` is non-null; if `-m` is specified, the `archivedModuleGraph` is null.
>> So running `java -version`, the archivedModuleGraph is non-null, but the module m won't be loaded from the archive. I'm seeing the following log output:
>> 
>> `[0.220s][debug][module     ] define_module(): creation of module: m, version: null, location: jrt:/m, loader data: 0x00007f201819dd60 for instance a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x000000011f010500}, package #: 1`
>
>> The `ArchivedModuleGraph.java` wasn't changed. So if `-m` is not specified, the `archivedModuleGraph` is non-null; if `-m` is specified, the `archivedModuleGraph` is null. So running `java -version`, the archivedModuleGraph is non-null, but the module m won't be loaded from the archive.
> 
> Right, but ArchivedModuleGraph provides the initial value for hasIncubatorModules, hasSplitPackages, ... This is why `java -version` confusingly prints a warning that an incubator module has been resolved. We've had archiving of the module graph (configuration) for a long time but it's only been for the case where the initial module is the unnamed module. I think archiving of the boot layer for the case where the initial module is a named module means we have to re-visit ArchivedModuleGraph. I think ArchivedModuleGraph.get has to return null when the archive doesn't match the mainModule. Part of it wonder if we should remove ArchivedModuleGraph, support archiving of the boot layer only.

I've added the following field in `ArchivedModuleGraph` so that the `get(String mainModuleName)` will check the `mainModule` before returning `archivedModuleGraph`.
`private static String mainModule;`
The `mainModule` field is also added in `heapShared.cpp` so that it is stored in the archive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1377099846

From alanb at openjdk.org  Tue Oct 31 06:56:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Oct 2023 06:56:36 GMT
Subject: RFR: 8315004: Runtime.halt() debug logging
In-Reply-To: <9dyKdOjb2grEjFxBeApwJ0NeP8vziPGEQrvTpf4kY0M=.9b642538-1142-491e-8fb3-d3c2382851c7@github.com>
References: 
 
 <9dyKdOjb2grEjFxBeApwJ0NeP8vziPGEQrvTpf4kY0M=.9b642538-1142-491e-8fb3-d3c2382851c7@github.com>
Message-ID: 

On Fri, 1 Sep 2023 08:29:41 GMT, Alan Bateman  wrote:

>> I think you may have missed the comment in the JBS issue. Logging means running potentially arbitrary code, doing this at Runtime.halt time is problematic. I thought the conclusion from the work on Runtime.exit was not to log in Runtime.halt?
>
>> @AlanBateman Sorry for missing your comment on JBS. I can't find any discussion of the need for logs in Runtime.halt in JDK-8301627, so I'm not sure if it was intentional that no logging output was added to Runtime.halt.
>> However, if Runtime.halt is overlooked without discussion, I think it should be added after considering the need.
>> I think it's the same problem as Runtime.exit when it comes to executing arbitrary code.
>> Are there any issues specific to Runtime.halt?
> 
> The purpose of the halt method is to terminate immediately, it doesn't initiate the shutdown sequence. My recollection of the System.exit logging is that it was deliberate to not change the halt method. Changing halt to log means it would not terminate immediately. Also I think there were concerns with logging libraries that needed the shutdown hook to execute in order to fush/close logs. @RogerRiggs or @stuart-marks may be able to say more about this.

> @AlanBateman @RogerRiggs Could you comment on the above?

Changing Runtime.halt to log means it would not terminate immediately. It's worse: Logging is pluggable so it means logging can potentially run "faraway" and arbitrary code. We have to super cautious with logging in core classes. The conclusion from the work on Runtime.exit was to not add this logging to Runtime.halt. So I don't think the changes in the PR should be integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1786553171

From jbhateja at openjdk.org  Tue Oct 31 07:19:55 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 31 Oct 2023 07:19:55 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi All,
> 
> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features.
> 
> Following is the summary of changes:-
> 
> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact
> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro.
> 
> 
> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d)
> 
> 
> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts.
> 
> 3) Some minor adjustments in existing gather instruction pattens for double/quad words.
> 
> 
> Kindly review and share your feedback.
> 
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Restricting masked sub-word gather to AVX512 target to align with integral gather support.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16354/files
  - new: https://git.openjdk.org/jdk/pull/16354/files/d0d6f455..86783403

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=01-02

  Stats: 93 lines in 2 files changed: 0 ins; 92 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16354.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16354/head:pull/16354

PR: https://git.openjdk.org/jdk/pull/16354

From lkorinth at openjdk.org  Tue Oct 31 07:25:49 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 31 Oct 2023 07:25:49 GMT
Subject: RFR: 8318962: Javadoc: Update ProcessTools after suggestions in
 8315097
Message-ID: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com>

Updates to javadoc after improvement ideas in the review of 8315097. I have also removed the incomplete invocation command line. I also removed incomplete information in `executeTestJvm` and added a link to `createLimitedTestJavaProcessBuilder`

-------------

Commit messages:
 - 8318962: Javadoc: Update ProcessTools after suggestions in 8315097

Changes: https://git.openjdk.org/jdk/pull/16430/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318962
  Stats: 70 lines in 1 file changed: 42 ins; 4 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16430/head:pull/16430

PR: https://git.openjdk.org/jdk/pull/16430

From lkorinth at openjdk.org  Tue Oct 31 07:49:41 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 31 Oct 2023 07:49:41 GMT
Subject: RFR: 8319153: Fix: Class is a raw type in ProcessTools
Message-ID: 

Changing from `Class c` to `Class c` removes two warnings.

-------------

Commit messages:
 - 8319153: Fix: Class is a raw type in ProcessTools

Changes: https://git.openjdk.org/jdk/pull/16431/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16431&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319153
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16431/head:pull/16431

PR: https://git.openjdk.org/jdk/pull/16431

From dholmes at openjdk.org  Tue Oct 31 08:16:32 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 31 Oct 2023 08:16:32 GMT
Subject: RFR: 8319153: Fix: Class is a raw type in ProcessTools
In-Reply-To: 
References: 
Message-ID: 

On Tue, 31 Oct 2023 07:43:43 GMT, Leo Korinth  wrote:

> Changing from `Class c` to `Class c` removes two warnings.

Looks fine and trivial.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16431#pullrequestreview-1705674609

From alanb at openjdk.org  Tue Oct 31 09:06:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Oct 2023 09:06:32 GMT
Subject: RFR: JDK-8319120: Unbound ScopedValue.get() throws the wrong
 exception [v2]
In-Reply-To: <1t8usU03GkKm23YwTWcB1pbl-J6lv4JisueZcjv-Gdc=.4df3e979-05a2-42b9-953a-d3db48aa9a99@github.com>
References: 
 <1t8usU03GkKm23YwTWcB1pbl-J6lv4JisueZcjv-Gdc=.4df3e979-05a2-42b9-953a-d3db48aa9a99@github.com>
Message-ID: 

On Mon, 30 Oct 2023 17:16:54 GMT, Andrew Haley  wrote:

>> The bug here is a thinko in `ScopedValue.scopedValueBindings()`.
>> 
>> If the JVM runs out of resources, we throw a `VirtualMachineError`. Running out of resources can happen at almost any time, and can happen while `ScopedValue`'s internal structures are being modified, leaving them in an inconsistent state. We detect when a `VirtualMachineError` happens and walk the stack to find the most-recent set of `ScopedValue` bindings.
>> 
>> When we crate a new `Thread`, we push a sentinel frame onto the stack that we can find in the case that we threw a `VirtualMachineError`. Threads created by the native invocation interface (rather than by Java threads) don't have that sentinel, so a search for it returns null. Therefore, in the rare cases where we have to do a stack walk, we must check for both `NEW_THREAD_BINDINGS` (the sentinel) and `null`. We weren't doing that, we were only checking for null.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16422#pullrequestreview-1705767019

From alanb at openjdk.org  Tue Oct 31 09:12:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Oct 2023 09:12:37 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 31 Oct 2023 06:11:50 GMT, Calvin Cheung  wrote:

>> Please review this changeset for adding support for `--module` (-m) option for CDS.
>> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used.
>> 
>> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments from Ioi and Alan

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16016#pullrequestreview-1705777611

From alanb at openjdk.org  Tue Oct 31 09:12:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Oct 2023 09:12:38 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 <5lYwJpqhgq2MEJ17xpslna437GsmZFAH5v3FyWRhh-Q=.83077177-f238-4cdb-b65d-06e013b4edaf@github.com>
 
 <6Uy4_u0RQeGKXwUYk8REFcRYlx1AuSgbyQSClrlwFLU=.8c21fcdb-89b4-4bfc-a812-e0bed27d0efe@github.com>
 
 
Message-ID: 

On Tue, 31 Oct 2023 06:17:34 GMT, Calvin Cheung  wrote:

> I've added the following field in `ArchivedModuleGraph` so that the `get(String mainModuleName)` will check the `mainModule` before returning `archivedModuleGraph`. `private static String mainModule;` The `mainModule` field is also added in `heapShared.cpp` so that it is stored in the archive.

Thanks, it looks correctly now.

One small question. At ModuleBootstrap L235 we set canArchive as it's okay to archive under specific restrictions. For completeness, shouldn't this set canArchive to CDS.isDumpingStaticArchive? I don't think it matters right now but might be confusing to have canArchive be true when not dumping.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1377263985

From alanb at openjdk.org  Tue Oct 31 10:49:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Oct 2023 10:49:35 GMT
Subject: RFR: JDK-8318467 : [jmh] tests concurrent.Queues and
 concurrent.ProducerConsumer hang with 101+ threads [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 30 Oct 2023 15:07:49 GMT, Viktor Klang  wrote:

>> Discussed with @DougLea and adjusting the queue capacity to at least the number of participating threads seems like the most sensible fix.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year and adjusting whitespace

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16419#pullrequestreview-1705992265

From alanb at openjdk.org  Tue Oct 31 11:14:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Oct 2023 11:14:34 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v7]
In-Reply-To: 
References: 
 <26zgN9543IcbQEum-nEsgfSv4v8412UkkJ412GszuXw=.44fa0b44-fc17-40d0-99a6-87d6d8be58a1@github.com>
 
Message-ID: 

On Mon, 16 Oct 2023 16:31:04 GMT, Brian Burkhalter  wrote:

> The CSR was created.

Thanks. I changed the "Compatibility Risk" to medium and expanded its description to more clearly explain the compatibility risk to fix this long standing issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1787004674

From vklang at openjdk.org  Tue Oct 31 11:16:42 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 31 Oct 2023 11:16:42 GMT
Subject: Integrated: JDK-8318467 : [jmh] tests concurrent.Queues and
 concurrent.ProducerConsumer hang with 101+ threads
In-Reply-To: 
References: 
Message-ID: <9QpRfySkFYx9TAjmgKjZIlW0wPPcQAQm5ApyacWRo6I=.b1b3ec6e-5b63-4223-ab05-480ccd8ae00e@github.com>

On Mon, 30 Oct 2023 14:54:08 GMT, Viktor Klang  wrote:

> Discussed with @DougLea and adjusting the queue capacity to at least the number of participating threads seems like the most sensible fix.

This pull request has now been integrated.

Changeset: e05cafda
Author:    Viktor Klang 
Committer: Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/e05cafda78a37dbeb2df2edd791be19d22edaece
Stats:     12 lines in 2 files changed: 6 ins; 0 del; 6 mod

8318467: [jmh] tests concurrent.Queues and concurrent.ProducerConsumer hang with 101+ threads

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/16419

From viktor.klang at oracle.com  Tue Oct 31 11:21:01 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 31 Oct 2023 11:21:01 +0000
Subject: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)
In-Reply-To: <218519414.39489013.1698705571799.JavaMail.zimbra@univ-eiffel.fr>
References: 
 <14E6FE7A-F8E0-4058-8C1A-B24C833CFD87@tylerkindy.com>
 
 <218519414.39489013.1698705571799.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: 


I will ask for a step further and add an overload to collect that takes a Gatherer and calls gather(gatherer).collect(Collectors.singleton()) so we can directly write
  var neatlyFolded = stream.collect(fold(...));

As a user, I see value in using the more powerful Gatherer API like a collector without having to think too much.

While I can definitely sympathize with this idea, very few Gatherers emit strictly a single element under all executions, and I'd expect that users will not always want that enforced by default (throwing an exception when number of elements not being strictly 1).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Remi Forax 
Sent: Monday, 30 October 2023 23:39
To: Viktor Klang 
Cc: Tyler Kindy ; core-libs-dev 
Subject: Re: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)



________________________________
From: "Viktor Klang" 
To: "Tyler Kindy" 
Cc: "core-libs-dev" 
Sent: Monday, October 30, 2023 10:59:48 PM
Subject: Re: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)
That's also a good point, and I've heard from multiple sources that sometimes you want to make sure that you only have a single element left at the end, and otherwise throw an exception.

Hello,


Fortunately it is possible to do something to the effect of:

// Proof of concept only
public static  Collector singleton() {
    class State { T value; boolean hasValue; }
    return Collector.of(
        State::new,
        (state, e) -> {
            if (state.hasValue)
                throw new IllegalStateException("Stream has more than one element!");

            state.hasValue = true;
            state.value = e;
        },
        (left, right) -> {
            if (left.hasValue && right.hasValue)
                throw new IllegalStateException("Stream has more than one element!");
            else if (left.hasValue)
                return left;
            else
                return right;
        },
        (state) -> {
            if (!state.hasValue)
                throw new IllegalStateException("Stream has less than one element!");
            else
                return state.value;
        });
}

Which means that you could write things like:

var neatlyFolded = stream.gather(fold(?)).collect(singleton());

I will ask for a step further and add an overload to collect that takes a Gatherer and calls gather(gatherer).collect(Collectors.singleton()) so we can directly write
  var neatlyFolded = stream.collect(fold(...));

As a user, I see value in using the more powerful Gatherer API like a collector without having to think too much.



Cheers,
?

regards,
R?mi



Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Tyler Kindy 
Sent: Monday, 30 October 2023 18:38
To: Viktor Klang 
Cc: core-libs-dev at openjdk.org 
Subject: Re: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)

Hi Viktor,

Thanks for the response! I see what you mean, it?s a good point that single-element streams are just as valid as streams with other numbers of elements.

The weird part for me, though, is getting the folded result out of the stream at the end (which, while not always, I believe will be the most common thing to want to do after `fold`). The obvious way, which you used in your presentation, is `findAny`. Since the stream could be empty, it makes sense that `findAny` returns an `Optional`, but with `fold` we know that the stream will have exactly one element in it.

Of course, this API is totally serviceable. You can use `Optional::orElseThrow` on the result of `findAny` to communicate your intent that you expect there to be an element. But that feels a bit roundabout to me; I feel that a cleaner API would be to get the folded result out directly, like how `Collector` works.

To your point, implementing `fold` as a Gatherer doesn?t mean we can never have a terminal `fold`. And having `fold` in any way at all is great; that?s one feature of Streams I commonly find myself wanting when writing code (the other is windowing, which I think you?ve covered the need for well; no notes on those \uD83D\uDE04).

But it does make me wish that `Collector` was also flexible enough to implement `fold`. Maybe a topic for future work. \uD83D\uDE04

Thanks again,
Tyler

On Oct 30, 2023, at 10:39?AM, Viktor Klang  wrote:

Hi Tyler,

Thank you for the kind words -- they are much appreciated. And you have a very good question indeed!

My thinking behind making fold a Gatherer is that I think that it is strictly more powerful than "only" having it as a collector (It wouldn't be able to be a Collector since you'd need a combiner for it, but also being able to compose it with other operations, choosing the output type at a later stage in the process, and so forth).

Also, if you think about it -- single-element Streams are just as valid as empty Streams, N-sized Streams, or even unbounded Streams, and conceptually, there's no difference between the following two Streams:

var a = Stream.of("1234")
var b = Stream.of(1,2,3,4).gather(fold(() -> "", (str, next) -> str + next))

So that was my thinking?allow developers to stay within Stream processing for as long as they want, and choose the terminal operation when they need to break out from the Stream.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Tyler Kindy 
Sent: Monday, 30 October 2023 12:14
To: Viktor Klang 
Cc: core-libs-dev at openjdk.org 
Subject: [External] : Re: Update on JEP-461: Stream Gatherers (Preview)

Thanks for the JEP and your talk, Viktor! I think `Stream::gather` will be super useful in my day-to-day as a Java developer.

I?m curious why `fold` is being implemented with gatherers. I recognize `Gatherer` is designed to support intermediate operations, but `fold` feels inherently like a terminal operation to me since it, like `reduce` or `collect`, consumes all the elements in the stream and produces a single result.

Is there a technical limitation to making `fold` a terminal operation? For example, does `Collector` inherently presume parallelization in a way that `Gatherer` does not?

Or is the idea mainly to demonstrate the power of gatherers, and we could also make `fold` a terminal operation with the current `Stream` API?

Thank you!
Tyler Kindy

On Oct 27, 2023, at 9:50?AM, Viktor Klang  wrote:

Greetings,

As you may have already seen,Stream Gatherersis now aPreview JEP with Candidate status

Work-in-progress (interfaces, implementation, tests, benches, and documentation) for JEP-461 is currently availablehere.

Whilethe designhas held up well, there are some important improvements made since the original design document was written.

Notable changes (without any particular order):

  *   Stream::gather()now has a default implementation.

  *   Gatherer::supplier()was renamed toGatherer::initializer()to better reflect intent.

  *   Gatherer.Sinkwas renamed toGatherer.Downstreamto better signal what it represents.

  *   Gatherer::collect(Collector)and its companion typeGatherer.ThenCollectorwas dropped due to compatibility concerns with existing code which operates onCollector.

  *
Gatherer.Characteristicshave been eliminated and superseded by having default values that are used as sentinels.
 (discussed further down the list)
This is important because with the Characteristics-model keeping alignment between Characteristics and actual implementation proved brittle, and under composition of Gatherers computing the union was inefficient and mostly lead to an empty set in the end.

  *   Gatherer.defaultInitializer(),Gatherer.defaultCombiner(), andGatherer.defaultFinisher()were added as static methods?these are the sentinels used to elide calling the initializer, to elide calling the combiner (avoid parallelization), and to elide calling the finisher, respectively.

  *   Gatherer::initializer(),Gatherer::combiner(), andGatherer::finisher()default implementations return the respective sentinels.

  *   A subtype ofIntegratornamedGreedywas added, together with a factory method to guide lambda-to-nominal-type conversion. This allows creators of Gatherers to signal that anIntegratorwill never initiate a short-circuit (but may relay one from downstream), and that is available during evaluation to determine if the operation can short-circuit or not.

  *   Factories for creating anonymous Gatherers were expanded upon to includeGatherer.of()andGatherer.ofSequential()with different sets of parameters, primarily to make it more ergonomical and easier to read and write the code using those factories.

  *   A curated set of initial built-in Gatherers is located injava.util.stream.Gatherers

I recently presentedGatherers at Devoxx, which I'd recommend watching for an introduction to the feature.

Teaching old Streams new tricks By Viktor Klang
Have you ever wanted to perform an operation on a java.util.stream.Stream only to find that the existing set of operations didn't provide what you needed?forcing you to break out early from the Stream and perform the logic outside of it? As a matter of fact, java.util.stream was the first JDK API designed with lambdas in mind and was ...
www.youtube.com


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From aph at openjdk.org  Tue Oct 31 13:01:42 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 31 Oct 2023 13:01:42 GMT
Subject: Integrated: JDK-8319120: Unbound ScopedValue.get() throws the wrong
 exception
In-Reply-To: 
References: 
Message-ID: 

On Mon, 30 Oct 2023 15:57:23 GMT, Andrew Haley  wrote:

> The bug here is a thinko in `ScopedValue.scopedValueBindings()`.
> 
> If the JVM runs out of resources, we throw a `VirtualMachineError`. Running out of resources can happen at almost any time, and can happen while `ScopedValue`'s internal structures are being modified, leaving them in an inconsistent state. We detect when a `VirtualMachineError` happens and walk the stack to find the most-recent set of `ScopedValue` bindings.
> 
> When we crate a new `Thread`, we push a sentinel frame onto the stack that we can find in the case that we threw a `VirtualMachineError`. Threads created by the native invocation interface (rather than by Java threads) don't have that sentinel, so a search for it returns null. Therefore, in the rare cases where we have to do a stack walk, we must check for both `NEW_THREAD_BINDINGS` (the sentinel) and `null`. We weren't doing that, we were only checking for null.

This pull request has now been integrated.

Changeset: ee6f25b5
Author:    Andrew Haley 
URL:       https://git.openjdk.org/jdk/commit/ee6f25b5072a26254f79381a92216357d9f391f9
Stats:     67 lines in 2 files changed: 62 ins; 1 del; 4 mod

8319120: Unbound ScopedValue.get() throws the wrong exception

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/16422

From duke at openjdk.org  Tue Oct 31 13:45:38 2023
From: duke at openjdk.org (null)
Date: Tue, 31 Oct 2023 13:45:38 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 27 Oct 2023 10:31:35 GMT, Alan Bateman  wrote:

> > Hey stuart-marks (cc liach @AlanBateman ExE-Boss), I think this discussion has stalled a bit. Would it be an idea to at least push this commit through.
> 
> No, as I don't think there is agreement yet on this direction. Also all of the options involve a spec change.

Fair enough. Is there something I can do to help further this? I would like to resolve this PR, but I'm not sure if people are waiting on something from me...?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1787246189

From rriggs at openjdk.org  Tue Oct 31 13:55:34 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 31 Oct 2023 13:55:34 GMT
Subject: RFR: 8318962: Javadoc: Update ProcessTools after suggestions in
 8315097
In-Reply-To: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com>
References: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com>
Message-ID: 

On Tue, 31 Oct 2023 07:19:53 GMT, Leo Korinth  wrote:

> Updates to javadoc after improvement ideas in the review of 8315097. I have also removed the incomplete invocation command line. I also removed incomplete information in `executeTestJvm` and added a link to `createLimitedTestJavaProcessBuilder`

test/lib/jdk/test/lib/process/ProcessTools.java line 612:

> 610:     /**
> 611:      * Executes a test jvm process, waits for it to finish and returns
> 612:      * the process output.

Dropping the support test.vm.opts and test.java.opts deserves to be explicitly documented.

Can you confirm that all existing uses no longer need the test options and have already been remediated in 8315097.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16430#discussion_r1377624163

From rriggs at openjdk.org  Tue Oct 31 13:57:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 31 Oct 2023 13:57:30 GMT
Subject: RFR: 8315004: Runtime.halt() debug logging
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Aug 2023 09:37:47 GMT, Masanori Yano  wrote:

> I want to add a log output similar to JDK-8301627 to Runtime.halt().
> To avoid double logging of Runtime.exit(), add a flag to indicate whether logging was done, and fix it so that logging is done only once.
> Could someone please review this fix?

As commented [above](https://github.com/openjdk/jdk/pull/15426#issuecomment-1703133971), this change should not be integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1787268727

From mli at openjdk.org  Tue Oct 31 15:18:33 2023
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 31 Oct 2023 15:18:33 GMT
Subject: RFR: 8319153: Fix: Class is a raw type in ProcessTools
In-Reply-To: 
References: 
Message-ID: 

On Tue, 31 Oct 2023 07:43:43 GMT, Leo Korinth  wrote:

> Changing from `Class c` to `Class c` removes two warnings.

LGTM

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16431#pullrequestreview-1706582873

From gbarany at openjdk.org  Tue Oct 31 16:01:32 2023
From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany)
Date: Tue, 31 Oct 2023 16:01:32 GMT
Subject: RFR: 8315680: java/lang/ref/ReachabilityFenceTest.java should run
 with -Xbatch
In-Reply-To: 
References: 
Message-ID: <3BE4TY-5dRuy6frHfNtVBSX0Hpfj_cQ98LqoEfAKs5A=.ddd8723f-6c36-4f13-9320-983831a5ddd6@github.com>

On Tue, 3 Oct 2023 07:47:30 GMT, Gerg? Barany  wrote:

> This test requires certain methods to be compiled, but without `-Xbatch` the compiler races against the test code, which can lead to intermittent failures.

@TobiHartmann might I ask you for a review of this trivial PR, or to suggest an appropriate reviewer from the HotSpot team?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16023#issuecomment-1787513113

From alanb at openjdk.org  Tue Oct 31 16:11:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Oct 2023 16:11:33 GMT
Subject: RFR: 8317609: Classfile API fails to verify
 /jdk.jcmd/sun/tools/jstat/Alignment.class
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 15:09:41 GMT, Adam Sotona  wrote:

> JImageValidator has been recently converted to use ClassFile API and original weak validation of class files was replaced with full class verification.
> Unfortunately full class verification is too strong as it includes class assignability verification according to class hierarchy resolution.
> This patch relaxes class assignability verification from JImageValidator by mocking ClassHierarchyResolver.
> Resolution of all classes as interfaces during verification effectively cancels the assignability verification (as interface assignability is not verified).
> 
> Please review this pull request.
> 
> Thanks,
> Adam

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16123#pullrequestreview-1706717719

From asotona at openjdk.org  Tue Oct 31 16:16:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 31 Oct 2023 16:16:42 GMT
Subject: RFR: 8317609: Classfile API fails to verify
 /jdk.jcmd/sun/tools/jstat/Alignment.class
In-Reply-To: 
References: 
 
Message-ID: <2Q1YESUZi9YTH1Z9Bawz2Br9myr6ScidTqo-wEcgrSk=.cc21094e-5a5a-4b76-a5cf-ca47abd5357d@github.com>

On Tue, 31 Oct 2023 16:08:54 GMT, Alan Bateman  wrote:

>> JImageValidator has been recently converted to use ClassFile API and original weak validation of class files was replaced with full class verification.
>> Unfortunately full class verification is too strong as it includes class assignability verification according to class hierarchy resolution.
>> This patch relaxes class assignability verification from JImageValidator by mocking ClassHierarchyResolver.
>> Resolution of all classes as interfaces during verification effectively cancels the assignability verification (as interface assignability is not verified).
>> 
>> Please review this pull request.
>> 
>> Thanks,
>> Adam
>
> Marked as reviewed by alanb (Reviewer).

@AlanBateman Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16123#issuecomment-1787537011

From asotona at openjdk.org  Tue Oct 31 16:16:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 31 Oct 2023 16:16:43 GMT
Subject: Integrated: 8317609: Classfile API fails to verify
 /jdk.jcmd/sun/tools/jstat/Alignment.class
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 Oct 2023 15:09:41 GMT, Adam Sotona  wrote:

> JImageValidator has been recently converted to use ClassFile API and original weak validation of class files was replaced with full class verification.
> Unfortunately full class verification is too strong as it includes class assignability verification according to class hierarchy resolution.
> This patch relaxes class assignability verification from JImageValidator by mocking ClassHierarchyResolver.
> Resolution of all classes as interfaces during verification effectively cancels the assignability verification (as interface assignability is not verified).
> 
> Please review this pull request.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: f1e87873
Author:    Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/f1e878739300ed37c686ba570423c6f8a9fb310f
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8317609: Classfile API fails to verify /jdk.jcmd/sun/tools/jstat/Alignment.class

Reviewed-by: liach, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/16123

From lkorinth at openjdk.org  Tue Oct 31 17:15:50 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 31 Oct 2023 17:15:50 GMT
Subject: RFR: 8318962: Javadoc: Update ProcessTools after suggestions in
 8315097 [v2]
In-Reply-To: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com>
References: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com>
Message-ID: <4QdnYoO6FPy2EtXd2zl_jCShZrUOyV-ZgMrYstHr_Io=.d66188a4-1b00-410f-a14c-b91a3afba6ea@github.com>

> Updates to javadoc after improvement ideas in the review of 8315097. I have also removed the incomplete invocation command line. I also removed incomplete information in `executeTestJvm` and added a link to `createLimitedTestJavaProcessBuilder`

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  executeTestJvm has never used the 'limited' api, fix my bad documentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16430/files
  - new: https://git.openjdk.org/jdk/pull/16430/files/7c5283a6..2414962b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16430&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16430/head:pull/16430

PR: https://git.openjdk.org/jdk/pull/16430

From lkorinth at openjdk.org  Tue Oct 31 17:19:32 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 31 Oct 2023 17:19:32 GMT
Subject: RFR: 8318962: Javadoc: Update ProcessTools after suggestions in
 8315097 [v2]
In-Reply-To: <4QdnYoO6FPy2EtXd2zl_jCShZrUOyV-ZgMrYstHr_Io=.d66188a4-1b00-410f-a14c-b91a3afba6ea@github.com>
References: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com>
 <4QdnYoO6FPy2EtXd2zl_jCShZrUOyV-ZgMrYstHr_Io=.d66188a4-1b00-410f-a14c-b91a3afba6ea@github.com>
Message-ID: 

On Tue, 31 Oct 2023 17:15:50 GMT, Leo Korinth  wrote:

>> Updates to javadoc after improvement ideas in the review of 8315097. I have also removed the incomplete invocation command line. I also removed incomplete information in `executeTestJvm` and added a link to `createLimitedTestJavaProcessBuilder`
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   executeTestJvm has never used the 'limited' api, fix my bad documentation

Sorry Roger, I went a bit funny in the head...

I updated the documentation to correctly state that the propagating API is used.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16430#issuecomment-1787646938

From rriggs at openjdk.org  Tue Oct 31 18:21:38 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 31 Oct 2023 18:21:38 GMT
Subject: RFR: 8318962: Javadoc: Update ProcessTools after suggestions in
 8315097 [v2]
In-Reply-To: <4QdnYoO6FPy2EtXd2zl_jCShZrUOyV-ZgMrYstHr_Io=.d66188a4-1b00-410f-a14c-b91a3afba6ea@github.com>
References: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com>
 <4QdnYoO6FPy2EtXd2zl_jCShZrUOyV-ZgMrYstHr_Io=.d66188a4-1b00-410f-a14c-b91a3afba6ea@github.com>
Message-ID: 

On Tue, 31 Oct 2023 17:15:50 GMT, Leo Korinth  wrote:

>> Updates to javadoc after improvement ideas in the review of 8315097. I have also removed the incomplete invocation command line. I also removed incomplete information in `executeTestJvm` and added a link to `createLimitedTestJavaProcessBuilder`
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   executeTestJvm has never used the 'limited' api, fix my bad documentation

WRT the bug title and PR title...

The leading "Javadoc:" implies a change to the javadoc tool. Perhaps

Update ProcessTools javadoc with suggestions in 8315097

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16430#issuecomment-1787744604

From darcy at openjdk.org  Tue Oct 31 20:21:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 31 Oct 2023 20:21:03 GMT
Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2
Message-ID: 

Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2.

-------------

Commit messages:
 - JDK-8319195: Move tier 1 vector API regression tests to tier 2

Changes: https://git.openjdk.org/jdk/pull/16437/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319195
  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16437/head:pull/16437

PR: https://git.openjdk.org/jdk/pull/16437

From darcy at openjdk.org  Tue Oct 31 20:21:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 31 Oct 2023 20:21:04 GMT
Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier
 2
In-Reply-To: 
References: 
Message-ID: 

On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy  wrote:

> Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2.

As a check on the semantics of the change, `jtreg -l ...` output for tier 1 and tier 2 before and after the patch:


$ diff tier1.txt tier1-patched.txt 
108,133d107
< jdk/incubator/vector/AddTest.java
< jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java
< jdk/incubator/vector/ByteMaxVectorTests.java
< jdk/incubator/vector/CovarOverrideTest.java
< jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java
< jdk/incubator/vector/DoubleMaxVectorTests.java
< jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java
< jdk/incubator/vector/FloatMaxVectorTests.java
< jdk/incubator/vector/ImageTest.java
< jdk/incubator/vector/IntMaxVectorLoadStoreTests.java
< jdk/incubator/vector/IntMaxVectorTests.java
< jdk/incubator/vector/LoadJsvmlTest.java
< jdk/incubator/vector/LongMaxVectorLoadStoreTests.java
< jdk/incubator/vector/LongMaxVectorTests.java
< jdk/incubator/vector/MethodOverideTest.java
< jdk/incubator/vector/MismatchTest.java
< jdk/incubator/vector/PreferredSpeciesTest.java#id0
< jdk/incubator/vector/PreferredSpeciesTest.java#id1
< jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java
< jdk/incubator/vector/ShortMaxVectorTests.java
< jdk/incubator/vector/VectorHash.java
< jdk/incubator/vector/VectorMaxConversionTests.java#id0
< jdk/incubator/vector/VectorMaxConversionTests.java#ZGenerational
< jdk/incubator/vector/VectorMaxConversionTests.java#ZSinglegen
< jdk/incubator/vector/VectorReshapeTests.java
< jdk/incubator/vector/VectorRuns.java
2410c2384
< Tests found: 2,408
---
> Tests found: 2,382

$ diff tier1.txt tier1-patched.txt 
108,133d107
< jdk/incubator/vector/AddTest.java
< jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java
< jdk/incubator/vector/ByteMaxVectorTests.java
< jdk/incubator/vector/CovarOverrideTest.java
< jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java
< jdk/incubator/vector/DoubleMaxVectorTests.java
< jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java
< jdk/incubator/vector/FloatMaxVectorTests.java
< jdk/incubator/vector/ImageTest.java
< jdk/incubator/vector/IntMaxVectorLoadStoreTests.java
< jdk/incubator/vector/IntMaxVectorTests.java
< jdk/incubator/vector/LoadJsvmlTest.java
< jdk/incubator/vector/LongMaxVectorLoadStoreTests.java
< jdk/incubator/vector/LongMaxVectorTests.java
< jdk/incubator/vector/MethodOverideTest.java
< jdk/incubator/vector/MismatchTest.java
< jdk/incubator/vector/PreferredSpeciesTest.java#id0
< jdk/incubator/vector/PreferredSpeciesTest.java#id1
< jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java
< jdk/incubator/vector/ShortMaxVectorTests.java
< jdk/incubator/vector/VectorHash.java
< jdk/incubator/vector/VectorMaxConversionTests.java#id0
< jdk/incubator/vector/VectorMaxConversionTests.java#ZGenerational
< jdk/incubator/vector/VectorMaxConversionTests.java#ZSinglegen
< jdk/incubator/vector/VectorReshapeTests.java
< jdk/incubator/vector/VectorRuns.java
2410c2384
< Tests found: 2,408
---
> Tests found: 2,382

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1787969532

From alanb at openjdk.org  Tue Oct 31 20:30:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 31 Oct 2023 20:30:31 GMT
Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier
 2
In-Reply-To: 
References: 
Message-ID: 

On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy  wrote:

> Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2.

jdk_vector_sanity was added by JDK-8295970 to get some coverage in tier1. That motivation should probably be re-examined. One thing that I don't like is that it maps to a list of specific tests so it's not very maintainable. I wonder if it could be removed and change jdk_vector to run in tier2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1787983800

From ccheung at openjdk.org  Tue Oct 31 20:47:36 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 31 Oct 2023 20:47:36 GMT
Subject: RFR: 8316969: Improve CDS module graph support for --module option
 [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 <5lYwJpqhgq2MEJ17xpslna437GsmZFAH5v3FyWRhh-Q=.83077177-f238-4cdb-b65d-06e013b4edaf@github.com>
 
 <6Uy4_u0RQeGKXwUYk8REFcRYlx1AuSgbyQSClrlwFLU=.8c21fcdb-89b4-4bfc-a812-e0bed27d0efe@github.com>
 
 
 
Message-ID: 

On Tue, 31 Oct 2023 09:09:37 GMT, Alan Bateman  wrote:

> Thanks, it looks correctly now.

Thanks!

> 
> One small question. At ModuleBootstrap L235 we set canArchive as it's okay to archive under specific restrictions. For completeness, shouldn't this set canArchive to CDS.isDumpingStaticArchive? I don't think it matters right now but might be confusing to have canArchive be true when not dumping.

Do you mean L230?

 226             if (!haveModulePath && addModules.isEmpty() && limitModules.isEmpty()) {
 227                 systemModules = SystemModuleFinders.systemModules(mainModule);
 228                 if (systemModules != null && !isPatched) {
 229                     needResolution = (traceOutput != null);
 230                     canArchive = true;
 231                 }
 232             }

Do you prefer the `canArchive` setting be inside `if (CDS.isDumpingStaticArchive())` like the following?

    if (CDS.isDumpingStaticArchive())
        canArchive = true;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1378146393

From lmesnik at openjdk.org  Tue Oct 31 23:33:59 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 31 Oct 2023 23:33:59 GMT
Subject: RFR: 8319153: Fix: Class is a raw type in ProcessTools
In-Reply-To: 
References: 
Message-ID: 

On Tue, 31 Oct 2023 07:43:43 GMT, Leo Korinth  wrote:

> Changing from `Class c` to `Class c` removes two warnings.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16431#pullrequestreview-1707376126


System properties