From liangchenblue at gmail.com Fri Sep 1 02:54:11 2023 From: liangchenblue at gmail.com (-) Date: Fri, 1 Sep 2023 10:54:11 +0800 Subject: Crash during optimizing exploded image with my patch Message-ID: Hello, I am trying to create a patch [1] that optimizes forEach for immutable factory collections (from List/Set.of) to see how it compares with constant-folded random access. However, this patch somehow tampers with exploded image optimization and modules during build, and I cannot build this patch on my windows 11 device. I have tried using both Oracle JDK 20 build 20+36-2344 (in JAVA_HOME) and the JDK 21 build 35 as boot JDK. JDK 20 fails with an IAE with message "Bad package name" (seems to be from modules.cpp) and JDK 21 fails with an NPE 'java.lang.NullPointerException: Cannot invoke " java.lang.module.ResolvedModule.name()" because "resolvedModules[index]" is null', both happening after reconfiguring and cleaning. These are my command-line: bash configure --with-boot-jdk=/cygdrive/c/java/boot/jdk-21 --enable-hsdis-bundling --with-hsdis=capstone --with-capstone=/cygdrive/c/java/capstone-4.0.2-win64 --with-jmh=build/jmh/jars --with-conf-name=windows-x64 --enable-jtreg-failure-handler Does anybody have any clue on why my patch fails the build? And how can I resolve this problem? Chen Liang [1] https://github.com/liachmodded/jdk/pull/new/feature/imm-coll-stream -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Sep 1 03:19:46 2023 From: duke at openjdk.org (airsquared) Date: Fri, 1 Sep 2023 03:19:46 GMT Subject: [jdk21] Withdrawn: 8309032: jpackage does not work for module projects unless --module-path is specified In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 02:34:05 GMT, airsquared wrote: > 8309032: jpackage does not work for module projects unless --module-path is specified This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk21/pull/140 From duke at openjdk.org Fri Sep 1 03:19:45 2023 From: duke at openjdk.org (airsquared) Date: Fri, 1 Sep 2023 03:19:45 GMT Subject: [jdk21] RFR: 8309032: jpackage does not work for module projects unless --module-path is specified In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 02:34:05 GMT, airsquared wrote: > 8309032: jpackage does not work for module projects unless --module-path is specified Created openjdk/jdk21u#120. ------------- PR Comment: https://git.openjdk.org/jdk21/pull/140#issuecomment-1702096153 From alanb at openjdk.org Fri Sep 1 06:15:37 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Sep 2023 06:15:37 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v9] In-Reply-To: <8wFp2rFtTWDGTQ4AKB4QYNjb0eJrg6aDznXP3p8agKE=.a0b699ac-f725-4bfd-9d07-bc7ace20b0a0@github.com> References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> <8wFp2rFtTWDGTQ4AKB4QYNjb0eJrg6aDznXP3p8agKE=.a0b699ac-f725-4bfd-9d07-bc7ace20b0a0@github.com> Message-ID: On Thu, 31 Aug 2023 14:29:41 GMT, iaroslavski 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1702220527 From duke at openjdk.org Fri Sep 1 07:04:50 2023 From: duke at openjdk.org (Christoph) Date: Fri, 1 Sep 2023 07:04:50 GMT Subject: RFR: 8315383: jlink SystemModulesPlugin incorrectly parses the options [v2] In-Reply-To: References: <8JLvIydPLtNKzBHiCLLM6Q4RbScQLPvShTSw_VtBn68=.ba04e37c-3ed6-46e0-be78-acee7ef3711f@github.com> Message-ID: <3Blfc6WjEurTHawJkv5yWSnM4kIcU5zV-lChZegTqAo=.91903048-b2bc-4a1f-b5a0-146aa67792a6@github.com> On Wed, 30 Aug 2023 19:30:37 GMT, Mandy Chung wrote: >> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove obsolete imports > > Looks good. Thanks for catching this. > > There are a few unused imports in JLinkDedupTestBatchSizeOne.java. Can you remove them as you are in that file? @mlchung Could you please do the backport for us? We don't have the rights. Thanks in advance! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15495#issuecomment-1702268892 From mbaesken at openjdk.org Fri Sep 1 07:29:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 1 Sep 2023 07:29:02 GMT Subject: RFR: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 Message-ID: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> on some RHEL Linux 8.X machines , we run into errors in test tools/jpackage/share/RuntimePackageTest.java#id0 , error can be seen below. It looks like these errors occur when running the jtreg tests with higher concurrency, I did not see them when running just the single test. When adding some test output , we see the 2 top install dirs below (1 is expected, not 2) : ./test/unpacked-rpm/opt ./test/unpacked-rpm/usr error output : java.lang.AssertionError: Expected [1]. Actual [2]: Check the package has 1 top installation directories at jdk.jpackage.test.TKit.error(TKit.java:273) at jdk.jpackage.test.TKit.assertEquals(TKit.java:576) at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:705) at jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$3(PackageTest.java:635) at java.base/java.util.Optional.ifPresent(Optional.java:178) at jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:633) at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:592) at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) at java.base/java.lang.Iterable.forEach(Iterable.java:75) at jdk.jpackage.test.PackageTest.lambda$runActions$24(PackageTest.java:381) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at jdk.jpackage.test.PackageTest.lambda$runActions$25(PackageTest.java:380) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at jdk.jpackage.test.PackageTest.runActions(PackageTest.java:379) at jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) at RuntimePackageTest.test(RuntimePackageTest.java:83) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762) at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:123) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:109) at jdk.jpackage.test.TKit.runTests(TKit.java:122) at jdk.jpackage.test.Main.runTests(Main.java:79) at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:109) at jdk.jpackage.test.Main.main(Main.java:75) 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) Looks like the additional dir /usr/lib/.build-id is coming from automatically adding /usr/lib/.build-id to package; this seems to be a feature of the rpmbuild according to https://bugzilla.redhat.com/show_bug.cgi?id=1724153 and must be configured in template.spec if it is unwanted. ------------- Commit messages: - JDK-8314121 Changes: https://git.openjdk.org/jdk/pull/15528/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15528&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314121 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15528/head:pull/15528 PR: https://git.openjdk.org/jdk/pull/15528 From alanb at openjdk.org Fri Sep 1 07:56:48 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Sep 2023 07:56:48 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v9] In-Reply-To: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> References: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> Message-ID: On Thu, 31 Aug 2023 17:09:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Merge > - Remove the new getInstance method taking varargs > - update mode to be int rather than long > - update tests > - Review feedback on javadoc > - Revised the API change. Add Option::DROP_METHOD_INFO > - Review feedback from Remi > - fixup javadoc > - Review feedback: move JLIA to ClassFrameInfo > - review feedback and javadoc clean up > - ... and 19 more: https://git.openjdk.org/jdk/compare/c8acab1d...111661bc The API changes in the the current update (111661bc) look good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1702328042 From myano at openjdk.org Fri Sep 1 08:21:38 2023 From: myano at openjdk.org (Masanori Yano) Date: Fri, 1 Sep 2023 08:21:38 GMT Subject: RFR: 8315004: Runtime.halt() debug logging In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 09:49:20 GMT, Alan Bateman 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? > > 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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1702358854 From pminborg at openjdk.org Fri Sep 1 08:31:13 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 1 Sep 2023 08:31:13 GMT Subject: RFR: 8315454: Add an immutable BitSet Message-ID: This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. The predicate is eligible for constant folding. Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: PoolReader (6) URLEncoder (1) - Updated in this PR HtmlTree (2) More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. Initial benchmarks with the URLEncoder show encouraging results: Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) ------------- Commit messages: - Add test and remove updates for some JDK classes Changes: https://git.openjdk.org/jdk/pull/15530/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15530&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315454 Stats: 153 lines in 3 files changed: 140 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/15530.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15530/head:pull/15530 PR: https://git.openjdk.org/jdk/pull/15530 From clanger at openjdk.org Fri Sep 1 08:32:20 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 1 Sep 2023 08:32:20 GMT Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows when run as user with Administrator privileges [v2] In-Reply-To: References: Message-ID: <6XbXvXBp_UUhj1UNGnSRwCzURb_DhWjX8CPOXJY5OjA=.383899d1-57be-400f-94bc-70b500d8ebfd@github.com> > On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible. Christoph Langer has updated the pull request with a new target base 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: - Use System.getProperty(user.name) for the Windows Adminstrators case - Merge branch 'master' into JDK-8314094 - JDK-8314094 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15222/files - new: https://git.openjdk.org/jdk/pull/15222/files/4e5cbf82..db6d3d14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15222&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15222&range=00-01 Stats: 27267 lines in 894 files changed: 17633 ins; 3604 del; 6030 mod Patch: https://git.openjdk.org/jdk/pull/15222.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15222/head:pull/15222 PR: https://git.openjdk.org/jdk/pull/15222 From alanb at openjdk.org Fri Sep 1 08:32:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Sep 2023 08:32:40 GMT Subject: RFR: 8315004: Runtime.halt() debug logging In-Reply-To: References: Message-ID: <9dyKdOjb2grEjFxBeApwJ0NeP8vziPGEQrvTpf4kY0M=.9b642538-1142-491e-8fb3-d3c2382851c7@github.com> On Fri, 25 Aug 2023 09:49:20 GMT, Alan Bateman 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? > > 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1702371738 From asotona at openjdk.org Fri Sep 1 08:35:58 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 1 Sep 2023 08:35:58 GMT Subject: RFR: 8313983: jmod create --target-platform should replace existing ModuleTarget attribute In-Reply-To: References: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com> Message-ID: On Thu, 31 Aug 2023 16:47:07 GMT, Mandy Chung wrote: > Would you consider documenting in the javadoc of XXXAttribute in the ClassFile API if it allows multiple? It will make clear to the readers. Yes, I'll add that information as a part of javadoc update #14968. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15514#issuecomment-1702375563 From asotona at openjdk.org Fri Sep 1 08:36:01 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 1 Sep 2023 08:36:01 GMT Subject: Integrated: 8313983: jmod create --target-platform should replace existing ModuleTarget attribute In-Reply-To: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com> References: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com> Message-ID: On Thu, 31 Aug 2023 12:13:40 GMT, Adam Sotona wrote: > ModuleTarget and ModuleResolution attributes were flagged as 'allow multiple' in the Classfile API. > This patch removed the flags and allows at most one instance of each attribute. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: c2e01eba Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/c2e01eba5a537acd573b7d2e6d41811c415c3f68 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8313983: jmod create --target-platform should replace existing ModuleTarget attribute Reviewed-by: alanb, mchung ------------- PR: https://git.openjdk.org/jdk/pull/15514 From clanger at openjdk.org Fri Sep 1 08:37:39 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 1 Sep 2023 08:37:39 GMT Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows when run as user with Administrator privileges [v2] In-Reply-To: References: <2qBOL4we7ScqNYGkXnHhZcEUjEwMEyHKDOuWAdmUP0I=.95096c0d-398f-41c3-b85e-8dfee1307ad5@github.com> Message-ID: On Thu, 31 Aug 2023 15:08:34 GMT, Roger Riggs wrote: >> The problem with the environment variables is, that jtreg only passes very few of them down to the testee process - USERDOMAIN and USERNAME are not part of these as far as I know. > > ok, more overhead than value in the suggestion. > If its windows, strip off the domain (before "/") and compare. > If that doesn't work then just drop the username compare on windows. After verifying that System.getenv yields empty results for USERDOMAIN and USERNAME, I updated the change to use System.getProperty("user.name") in the Windows Administrators case. Let's see how testing goes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15222#discussion_r1312738642 From liach at openjdk.org Fri Sep 1 08:53:38 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 1 Sep 2023 08:53:38 GMT Subject: RFR: 8315454: Add an immutable BitSet In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 08:21:13 GMT, Per Minborg wrote: > This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: > > PoolReader (6) > URLEncoder (1) - Updated in this PR > HtmlTree (2) > > More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. > > Initial benchmarks with the URLEncoder show encouraging results: > > > Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% > URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) What about the missing functionalities, such as ranged get, cardinality, next/previousSet/ClearBit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15530#issuecomment-1702400105 From hgreule at openjdk.org Fri Sep 1 09:03:39 2023 From: hgreule at openjdk.org (Hannes Greule) Date: Fri, 1 Sep 2023 09:03:39 GMT Subject: RFR: 8315454: Add an immutable BitSet In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 08:21:13 GMT, Per Minborg wrote: > This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: > > PoolReader (6) > URLEncoder (1) - Updated in this PR > HtmlTree (2) > > More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. > > Initial benchmarks with the URLEncoder show encouraging results: > > > Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% > URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) Maybe it would make sense to start with a JDK-internal variant before exploring potential public API? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15530#issuecomment-1702412714 From pminborg at openjdk.org Fri Sep 1 09:10:38 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 1 Sep 2023 09:10:38 GMT Subject: RFR: 8315454: Add an immutable BitSet In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 08:50:42 GMT, Chen Liang wrote: > What about the missing functionalities, such as ranged get, cardinality, next/previousSet/ClearBit? This was explored in https://github.com/openjdk/jdk/pull/15493 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15530#issuecomment-1702419694 From pminborg at openjdk.org Fri Sep 1 09:10:40 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 1 Sep 2023 09:10:40 GMT Subject: RFR: 8315454: Add an immutable BitSet In-Reply-To: References: Message-ID: <28MB4IVOTMVjG491Gv640fwFJ2iNpHPzBhygkxuZ63E=.7ac764f5-d497-4603-b8c3-f8027f29503e@github.com> On Fri, 1 Sep 2023 09:00:32 GMT, Hannes Greule wrote: > Maybe it would make sense to start with a JDK-internal variant before exploring potential public API? This is certainly one alternative. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15530#issuecomment-1702421871 From mcimadamore at openjdk.org Fri Sep 1 09:38:39 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 1 Sep 2023 09:38:39 GMT Subject: RFR: 8315454: Add an immutable BitSet In-Reply-To: <28MB4IVOTMVjG491Gv640fwFJ2iNpHPzBhygkxuZ63E=.7ac764f5-d497-4603-b8c3-f8027f29503e@github.com> References: <28MB4IVOTMVjG491Gv640fwFJ2iNpHPzBhygkxuZ63E=.7ac764f5-d497-4603-b8c3-f8027f29503e@github.com> Message-ID: On Fri, 1 Sep 2023 09:07:34 GMT, Per Minborg wrote: > > Maybe it would make sense to start with a JDK-internal variant before exploring potential public API? > > This is certainly one alternative. When looking at this I thought about that too. It seems like the particular case where this optimization is applicable is very specific, and I'm on the fence as to whether this deserves a public API. At the same time, there might be near-misses that could be difficult to address once the API is set in stone. I'd suggest to let it bake (inside the JDK) for some time, and later on decide whether it should be exposed as a public API. All that said, the idea of exposing a fast predicate over an immutable snapshot is very cute and clever :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15530#issuecomment-1702462814 From duke at openjdk.org Fri Sep 1 09:56:40 2023 From: duke at openjdk.org (Viktor Klang) Date: Fri, 1 Sep 2023 09:56:40 GMT Subject: RFR: 8315454: Add an immutable BitSet In-Reply-To: References: Message-ID: <2Xq5NBU4yXbe4Nqbaleoe2K-mc9NkIOwKGCRovI7bfM=.8217c039-bcb0-4da6-81dd-129def1349fb@github.com> On Fri, 1 Sep 2023 08:21:13 GMT, Per Minborg wrote: > This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: > > PoolReader (6) > URLEncoder (1) - Updated in this PR > HtmlTree (2) > > More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. > > Initial benchmarks with the URLEncoder show encouraging results: > > > Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% > URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) src/java.base/share/classes/java/util/BitSet.java line 1412: > 1410: *

> 1411: * Returned predicates are threadsafe and can be used without external synchronisation. Furthermore, > 1412: * they are eligible for constant-folding optimization by the VM. > Furthermore, * they are eligible for constant-folding optimization by the VM. I'd probably skip this unless there's prior art to describe the constant-fold-eligibility of returned values from methods. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15530#discussion_r1312826139 From mgronlun at openjdk.org Fri Sep 1 10:50:40 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 1 Sep 2023 10:50:40 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 19:28:50 GMT, Alan Bateman wrote: >> There are some native methods that we execute during mount/unmount transitions. From what I see they all seem to be defined as `@IntrinsicCandidate`, but if for some reason we don't execute the intrinsic version (interp only mode for instance) then we would call a normal native method. > > Just to add that Patricio suggested today to run the stress tests with -Xint and that does lead to triggering the assert quickly when the thread is sampled in native. There are several native methods that are @IntrinsicCandidate that are invoked after the thread identity has changed to the virtual thread and before the continuation is mounted. Probably less likely on the unmount as the only native method is the one that reverts the thread identity. Ok. If the thread can run native code as part of the mount / unmount, and the sampler can see the intermediary state there too, the check is needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1312875905 From mgronlun at openjdk.org Fri Sep 1 10:53:39 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 1 Sep 2023 10:53:39 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman wrote: > In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM. > > The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition. > > Testing: tier1-5 Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15492#pullrequestreview-1606720202 From duke at openjdk.org Fri Sep 1 11:02:55 2023 From: duke at openjdk.org (iaroslavski) Date: Fri, 1 Sep 2023 11:02:55 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30] In-Reply-To: References: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com> Message-ID: On Wed, 30 Aug 2023 15:10:45 GMT, Srinivas Vamsi Parasa wrote: >>> Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags >> >> Just to add that Sorting.java has short and long run modes. The default when running with jtreg or make run-test is the short run so that it doesn't take too long. It might be useful to try it without -shortrun to give the intrinsic a better work out. > >> @AlanBateman If it helps, the changes made by @vamsi-parasa to DualPivotQuickSort.java don't change the logic as written in Java. They only carve out the functionality into separate Java methods retaining the meaning exactly as before. These Java methods are then optimized through a stub. > > Hi Alan, > > As Sandhya (@sviswa7) mentioned, this PR does not make any logic changes to the DualPivotQuickSort.java. > > The code was refactored to separate out the partitioning logic (dual pivot and single pivot) into separate methods. These methods are being intrinsified using AVX512 to do vectorized partitioning preserving the logic of Java side. Similarly, the methods to sort small arrays (insertionSort/mixedInsertionSort) are being intrinsified as well to use AVX512 sort while preserving the logic on Java side. > > Could you please go through the changes and provide your comments and suggestions? > > Thanks, > Vamsi Hi Vamsi (@vamsi-parasa)! Please see my few questions/suggestions related to method arraySort() and other code. **1.** If size < MIN_FAST_SMALL_ARRAY_SORT_SIZE (=16), you don't go into intrinsic arraySort(), method mixedInsertionSort is invoked instead. `if (size < MAX_MIXED_INSERTION_SORT_SIZE + bits && (bits & 1) > 0) {` ` int last = high - 3 * ((size >> 5) << 3);` ` if (size < MIN_FAST_SMALL_ARRAY_SORT_SIZE) mixedInsertionSort(a, low, last , high);` ` else arraySort(int.class, a, baseOffset, low, high, last);` ` return;` `}` Is Java mixedInsertionSort actually faster than intrinsic arraySort() on small (< 16) arrays? What if you try to invoke arraySort() on all small arrays and don't use constant MIN_FAST_SMALL_ARRAY_SORT_SIZE at all? Like this: `if (size < MAX_MIXED_INSERTION_SORT_SIZE + bits && (bits & 1) > 0) {` ` int last = high - 3 * ((size >> 5) << 3);` ` arraySort(int.class, a, baseOffset, low, high, last);` ` return;` `}` Could you please check and benchmark it? **2.** On the next step you apply the same approach when you invoke insertionSort() on the small leftmost part. `if (size < MAX_INSERTION_SORT_SIZE) {` ` if (size < MIN_FAST_SMALL_ARRAY_SORT_SIZE) insertionSort(a, low, high);` ` else arraySort(int.class, a, baseOffset, low, high, -1);` ` return;` `}` But this invocation happens only once, on the leftmost part only. I think we can invoke Java code and don't go to intrinsic arraySort(). I guess we will not have profit with intrinsic method here. See: `if (size < MAX_INSERTION_SORT_SIZE) {` ` insertionSort(a, low, high);` ` return;` `}` Could you please try this case without intrinsic and benchmark it? **3.** You introduce constant int baseOffset = Unsafe.ARRAY_INT_BASE_OFFSET inside the loop. What if we pass the constant directly? For example: `arraySort(int.class, a, Unsafe.ARRAY_INT_BASE_OFFSET, low, high, last);` **4.** You define 'int[] pivotIndices;' at the beginning of the loop, but the indices will be used later (or not used at all). My proposal to declare pivotIndices in if-then-else, see: `int[] pivotIndices = new int[] {e1, e5};` **5.** Method arrayPartition has argument isDualPivot, I think we can avoid it. If isDualPivot is true, pivot indices are different. If indices are equal, it means single pivot partitioning. So, changes are: `private static void arrayPartition(Class elemType, Object array, long offset, int low, int high, int[] pivotIndices) {` ` if (pivotIndices[0] == pivotIndices[1]) partitionSinglePivot(array, low, high, pivotIndices);` ` else partitionDualPivot(array, low, high, pivotIndices);` `}` **6.** Please add brackets for 'then' and 'else' statements according to common Java style: `if (pivotIndices[0] == pivotIndices[1]) {` ` partitionSinglePivot(array, low, high, pivotIndices);` `} else {` ` partitionDualPivot(array, low, high, pivotIndices);` `};` Thank you, Vladimir ------------- PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1702565544 From redestad at openjdk.org Fri Sep 1 11:09:42 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 1 Sep 2023 11:09:42 GMT Subject: RFR: 8315454: Add an immutable BitSet In-Reply-To: References: Message-ID: <6gxAe49HNwGrTBK30bYlLduEo9lNyhJH-sZ3nKaoThI=.002f4683-697e-4b03-ac50-493393a9a83b@github.com> On Fri, 1 Sep 2023 08:21:13 GMT, Per Minborg wrote: > This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: > > PoolReader (6) > URLEncoder (1) - Updated in this PR > HtmlTree (2) > > More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. > > Initial benchmarks with the URLEncoder show encouraging results: > > > Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% > URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) While I think this minimal API could well prove to be a useful addition to many projects, this was conceived on a whim and while it's sufficient for `URLEncoder` and a few internal users, there's no evidence that this API fits the needs of third-party code. I'd be happy with an internal implementation initially. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15530#issuecomment-1702576346 From alanb at openjdk.org Fri Sep 1 11:29:39 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Sep 2023 11:29:39 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 10:47:25 GMT, Markus Gr?nlund wrote: >> Just to add that Patricio suggested today to run the stress tests with -Xint and that does lead to triggering the assert quickly when the thread is sampled in native. There are several native methods that are @IntrinsicCandidate that are invoked after the thread identity has changed to the virtual thread and before the continuation is mounted. Probably less likely on the unmount as the only native method is the one that reverts the thread identity. > > Ok. If the thread can run native code as part of the mount / unmount, and the sampler can see the intermediary state there too, the check is needed. Thanks. One other thing that I see when more testing with generational ZGC is that ZPageAllocator::alloc_page will record an event and this can happen during a mount transition. So I think JfrStackTrace::record also needs to test if the current thread is a virtual thread without a continuation mounted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1312910082 From duke at openjdk.org Fri Sep 1 11:30:41 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 1 Sep 2023 11:30:41 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v13] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Thu, 31 Aug 2023 19:53:17 GMT, Claes Redestad wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> assert bounds check > > src/java.base/share/classes/java/lang/StringUTF16.java line 1585: > >> 1583: buf, >> 1584: Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1), >> 1585: PACKED_DIGITS_UTF16[r]); > > What performance would you get if you used the same lookup table as the other implementations, but inflate the value to UTF-16 on the fly? > > > int packed = (int)Integer.PACKED_DIGITS[r]; > int inflated = ((packed & 0xFF00) << 8) | (packed & 0xFF)); > UNSAFE.putIntUnaligned( > buf, > Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1), > inflated); > > > This would avoid juggling more lookup table data around than before, alleviating some of the concerns voiced in this PR comment thread. Good suggestion, using the same lookup table, we can get similar performance. int packed = (int) Integer.PACKED_DIGITS[-i]; int inflated = ((packed & 0xFF00) << 8) | (packed & 0xFF); charPos -= 2; assert charPos >= 0 && charPos < buf.length : "Trusted caller missed bounds check"; UNSAFE.putIntUnaligned( buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1), inflated, false); The performance comparison data is as follows: -Benchmark Mode Cnt Score Error Units -StringBuilders.toStringCharWithInt8UTF16 avgt 15 26.812 ? 0.095 ns/op +Benchmark Mode Cnt Score Error Units (use same lookup table) +StringBuilders.toStringCharWithInt8UTF16 avgt 15 27.807 ? 0.046 ns/op ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1312910616 From mgronlun at openjdk.org Fri Sep 1 11:35:42 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 1 Sep 2023 11:35:42 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing In-Reply-To: References: Message-ID: <4v3bHT95mK5u1ij2cXIK-UUnL_-Y0D-hTaSMRtfEr2g=.57272997-e290-4c2d-9d10-8a30bd742825@github.com> On Fri, 1 Sep 2023 11:26:48 GMT, Alan Bateman wrote: >> Ok. If the thread can run native code as part of the mount / unmount, and the sampler can see the intermediary state there too, the check is needed. > > Thanks. One other thing that I see when more testing with generational ZGC is that ZPageAllocator::alloc_page will record an event and this can happen during a mount transition. So I think JfrStackTrace::record also needs to test if the current thread is a virtual thread without a continuation mounted. That is not good. Such a check would be attributed to all event sites, making them all slower. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1312915249 From dl at openjdk.org Fri Sep 1 11:39:50 2023 From: dl at openjdk.org (Doug Lea) Date: Fri, 1 Sep 2023 11:39:50 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v19] 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: Fix tests, undo workarounds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14301/files - new: https://git.openjdk.org/jdk/pull/14301/files/4b12ddc9..53599566 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=17-18 Stats: 45 lines in 2 files changed: 15 ins; 5 del; 25 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 Fri Sep 1 11:40:14 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 1 Sep 2023 11:40:14 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v14] In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: > Optimization for: > Integer.toString > Long.toString > StringBuilder#append(int) > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.Integers.toString*" > make test TEST="micro:java.lang.Longs.toString*" > make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op > -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op > -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) > +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) > +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) > > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op > -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) > +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op > > +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) > > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op > -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op > -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ? 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... ??? has updated the pull request incrementally with one additional commit since the last revision: UTF16 & Latin1 use same lookup table ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14699/files - new: https://git.openjdk.org/jdk/pull/14699/files/a69f6d2a..d8a3d676 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=12-13 Stats: 59 lines in 1 file changed: 23 ins; 31 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699 PR: https://git.openjdk.org/jdk/pull/14699 From duke at openjdk.org Fri Sep 1 12:04:42 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 1 Sep 2023 12:04:42 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v13] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Thu, 31 Aug 2023 02:36:09 GMT, ??? wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> assert bounds check > > @cl4es can you help me to review this PR? > @wenshao How about of approach used in [James Anhalt's algorithm](https://jk-jeon.github.io/posts/2022/02/jeaiii-algorithm/)? > > It reduces number of multiplications ([and store operations in case of writing by 4-8 byte words](https://github.com/plokhotnyuk/jsoniter-scala/blob/b1020bafa7e2e5b7e8dd87b86a9e860975f4695e/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L2004-L2023)) but increases the total number of instructions for the routine. If the compiled code size is greater than 325 (FreqInlineSize), it will not be inlined and performance will slow down. This algorithm obviously greater than 325. different algorithms perform differently on different types of tiny/small/big values. The [first commit](https://github.com/openjdk/jdk/pull/14699/files/8bdda26b8bb7f6162592a07445ecd2285e4fabaa) of this PR performs better under big values. But I still use the current algorithm, with few changes, and performance can be improved in all scenarios. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1702637851 From asotona at openjdk.org Fri Sep 1 12:13:05 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 1 Sep 2023 12:13:05 GMT Subject: RFR: 8312491: Update Classfile API snippets and examples [v11] In-Reply-To: References: Message-ID: <9AeWVRa_vXQkxUREwK8DnJYAmpDRkFoIQ21Y9_FYMP4=.537b8e72-58c3-4357-89b9-7db96756516a@github.com> > This pull request updates Classfile API snippets and examples and adds missing javadoc. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: added notes to attributes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14968/files - new: https://git.openjdk.org/jdk/pull/14968/files/f4f74cac..ac8709c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=09-10 Stats: 135 lines in 37 files changed: 132 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14968.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968 PR: https://git.openjdk.org/jdk/pull/14968 From mbaesken at openjdk.org Fri Sep 1 12:36:28 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 1 Sep 2023 12:36:28 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: > We run into some BackingStoreException: Couldn't get file lock. e.g. here : > > [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) > [JShell] ... 4 more > > The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: add for some errnos also the string ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15308/files - new: https://git.openjdk.org/jdk/pull/15308/files/49519782..9230e1e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15308&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15308&range=00-01 Stats: 32 lines in 1 file changed: 26 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15308.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15308/head:pull/15308 PR: https://git.openjdk.org/jdk/pull/15308 From mbaesken at openjdk.org Fri Sep 1 12:36:30 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 1 Sep 2023 12:36:30 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken wrote: > We run into some BackingStoreException: Couldn't get file lock. e.g. here : > > [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) > [JShell] ... 4 more > > The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding I added the output of some errno related strings (like EACCES) to the exceptions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1702671601 From duke at openjdk.org Fri Sep 1 12:38:32 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 1 Sep 2023 12:38:32 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v15] In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: <-hizKZVHki82vjJ52oLoeR_uFna3taiUeL_YtOwoIKI=.b4673666-53c8-409b-a9e7-c59ee96ac8bf@github.com> > Optimization for: > Integer.toString > Long.toString > StringBuilder#append(int) > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.Integers.toString*" > make test TEST="micro:java.lang.Longs.toString*" > make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op > -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op > -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) > +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) > +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) > > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op > -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) > +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op > > +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) > > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op > -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op > -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ? 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... ??? has updated the pull request incrementally with one additional commit since the last revision: remove unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14699/files - new: https://git.openjdk.org/jdk/pull/14699/files/d8a3d676..cf2f8395 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699 PR: https://git.openjdk.org/jdk/pull/14699 From erik.joelsson at oracle.com Fri Sep 1 12:41:18 2023 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 1 Sep 2023 05:41:18 -0700 Subject: Crash during optimizing exploded image with my patch In-Reply-To: References: Message-ID: Hello Chen Liang, The exploded image optimization step runs the newly built JDK (in the exploded image) to generate data for itself. This means that if you change something fundamental in the JDK core libraries or the JVM, that may cause crashes in this build step. To diagnose further, you can run/debug the exploded image directly. /Erik On 8/31/23 19:54, - wrote: > Hello, > I am trying to create a patch [1] that optimizes forEach for immutable > factory collections (from List/Set.of) to see how it compares with > constant-folded random access. However, this patch somehow tampers > with exploded image optimization and modules during build, and I > cannot build this patch on my windows 11 device. > > I have tried using both Oracle JDK 20?build 20+36-2344 (in JAVA_HOME) > and the JDK 21 build 35 as boot JDK. JDK 20 fails with an IAE with > message "Bad package name" (seems to be from modules.cpp) and JDK 21 > fails with an NPE 'java.lang.NullPointerException: Cannot invoke > "java.lang.module.ResolvedModule.name > ()" because > "resolvedModules[index]" is null', both happening after reconfiguring > and cleaning. These are my command-line: > > bash configure --with-boot-jdk=/cygdrive/c/java/boot/jdk-21 > --enable-hsdis-bundling --with-hsdis=capstone > --with-capstone=/cygdrive/c/java/capstone-4.0.2-win64 > --with-jmh=build/jmh/jars --with-conf-name=windows-x64 > --enable-jtreg-failure-handler > > Does anybody have any clue on why my patch fails the build? And how > can I resolve this problem? > > Chen Liang > > [1] https://github.com/liachmodded/jdk/pull/new/feature/imm-coll-stream -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdoerr at openjdk.org Fri Sep 1 12:49:43 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 1 Sep 2023 12:49:43 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: On Fri, 1 Sep 2023 12:36:28 GMT, Matthias Baesken wrote: >> We run into some BackingStoreException: Couldn't get file lock. e.g. here : >> >> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) >> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) >> [JShell] ... 4 more >> >> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add for some errnos also the string Nice improvement! Please see my minor comments. src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 723: > 721: } > 722: return ""; > 723: } Would be a nice use case of switch expressions. But, I'm ok with it. src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 731: > 729: if (errCode != 0) { > 730: String errStr = getErrorString(errCode); > 731: if (! errStr.equals("")) errStr = " (" + errStr + ")"; Coding style: whitespace after '!' src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 732: > 730: String errStr = getErrorString(errCode); > 731: if (! errStr.equals("")) errStr = " (" + errStr + ")"; > 732: throw(new BackingStoreException("Couldn't get file lock. errno is " + errCode + errStr)); Strange coding style (also in the original code). I'd use "throw new ...". src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 798: > 796: if (!shared) sharingMode = "nonshared"; > 797: String errStr = getErrorString(errCode); > 798: if (! errStr.equals("")) errStr = " (" + errStr + ")"; as above src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 799: > 797: String errStr = getErrorString(errCode); > 798: if (! errStr.equals("")) errStr = " (" + errStr + ")"; > 799: throw(new BackingStoreException("Couldn't get file lock. errno is " + errCode + errStr + " mode is " + sharingMode)); as above ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15308#pullrequestreview-1606876656 PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1312979770 PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1312980202 PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1312982035 PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1312982899 PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1312983075 From alanb at openjdk.org Fri Sep 1 12:54:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Sep 2023 12:54:41 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: On Fri, 1 Sep 2023 12:36:28 GMT, Matthias Baesken wrote: >> We run into some BackingStoreException: Couldn't get file lock. e.g. here : >> >> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) >> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) >> [JShell] ... 4 more >> >> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add for some errnos also the string src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 722: > 720: case 1: return "EPERM"; > 721: } > 722: return ""; I assume the use of System.getProperty is problematic when running with a SM. In any case, I don't think this is the right way to do it, instead you want a native method to call strerror to translate the error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1312988133 From mbaesken at openjdk.org Fri Sep 1 13:09:41 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 1 Sep 2023 13:09:41 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: On Fri, 1 Sep 2023 12:36:28 GMT, Matthias Baesken wrote: >> We run into some BackingStoreException: Couldn't get file lock. e.g. here : >> >> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) >> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) >> [JShell] ... 4 more >> >> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add for some errnos also the string Hi Alan, > If there are only a couple of errno's that occur for these cases, it might be easier to hardwire the translation. I just followed the idea suggested above to do the translation in the Java class itself . Do you have a good example where it is done by strerror and then passed back to Java , without much overhead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1702721259 From mbaesken at openjdk.org Fri Sep 1 13:14:43 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 1 Sep 2023 13:14:43 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: On Fri, 1 Sep 2023 12:36:28 GMT, Matthias Baesken wrote: >> We run into some BackingStoreException: Couldn't get file lock. e.g. here : >> >> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) >> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) >> [JShell] ... 4 more >> >> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add for some errnos also the string Hi Alan , Your assumption 'I assume the use of System.getProperty is problematic when running with a SM.' is most likely correct. java.desktop/share/classes/sun/awt/FontConfiguration.java-133- protected void setOsNameAndVersion() { java.desktop/share/classes/sun/awt/FontConfiguration.java:134: osName = System.getProperty("os.name"); java.desktop/share/classes/sun/awt/FontConfiguration.java-135- osVersion = System.getProperty("os.version"); java.desktop/share/classes/sun/awt/FontConfiguration.java-136- } java.desktop/share/classes/sun/awt/FontConfiguration.java-137- -- java.management/share/classes/javax/management/loading/MLet.java-1054- // the architecture-specific path name. e.g. if user java.management/share/classes/javax/management/loading/MLet.java-1055- // requested a load for "foo" on Solaris SPARC 5.7 we try to java.management/share/classes/javax/management/loading/MLet.java-1056- // load "SunOS/sparc/5.7/lib/libfoo.so" from the JAR file. java.management/share/classes/javax/management/loading/MLet.java-1057- // java.management/share/classes/javax/management/loading/MLet.java:1058: nativelibname = removeSpace(System.getProperty("os.name")) + File.separator + java.management/share/classes/javax/management/loading/MLet.java-1059- removeSpace(System.getProperty("os.arch")) + File.separator + java.management/share/classes/javax/management/loading/MLet.java-1060- removeSpace(System.getProperty("os.version")) + File.separator + java.management/share/classes/javax/management/loading/MLet.java-1061- "lib" + File.separator + nativelibname; java.management/share/classes/javax/management/loading/MLet.java-1062- if (MLET_LOGGER.isLoggable(Level.TRACE)) { -- java.management/share/classes/sun/management/VMManagementImpl.java-223- // Operating System java.management/share/classes/sun/management/VMManagementImpl.java-224- public String getOsName() { java.management/share/classes/sun/management/VMManagementImpl.java:225: return System.getProperty("os.name"); java.management/share/classes/sun/management/VMManagementImpl.java-226- } java.management/share/classes/sun/management/VMManagementImpl.java-227- public String getOsArch() { java.management/share/classes/sun/management/VMManagementImpl.java-228- return System.getProperty("os.arch"); java.management/share/classes/sun/management/VMManagementImpl.java-229- } -- jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java-99- jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java-100- private Context context; jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java-101- jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java-102- private static final boolean isWindows = jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java:103: System.getProperty("os.name").startsWith("Windows"); jdk.compiler/share/classes/com/sun/tools/javac/jvm/JNIWriter.java-104- -- jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java-29- jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java-30-public class PlatformInfo { jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java-31- /* Returns "win32" if Windows; "linux" if Linux. */ jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java-32- public static String getOS() throws UnsupportedPlatformException { jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java:33: String os = System.getProperty("os.name"); jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java-34- if (os.equals("Linux")) { jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java-35- return "linux"; jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java-36- } else if (os.equals("FreeBSD")) { jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java-37- return "bsd"; -- jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ExecPty.java-131- } jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ExecPty.java:132: String undef = System.getProperty("os.name").toLowerCase().startsWith("hp") ? "^-" : "undef"; jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ExecPty.java-133- for (ControlChar cchar : ControlChar.values()) { jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ExecPty.java-134- int v = attr.getControlChar(cchar); jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ExecPty.java-135- if (v >= 0 && v != current.getControlChar(cchar)) { jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ExecPty.java-136- String str = ""; -- jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java-28- jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java-29- static void diag(PrintStream out) { jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java-30- out.println("System properties"); jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java-31- out.println("================="); jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java:32: out.println("os.name = " + System.getProperty("os.name")); jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java-33- out.println("OSTYPE = " + System.getenv("OSTYPE")); jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java-34- out.println("MSYSTEM = " + System.getenv("MSYSTEM")); jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java-35- out.println("PWD = " + System.getenv("PWD")); jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/Diag.java-36- out.println("ConEmuPID = " + System.getenv("ConEmuPID")); -- jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-13-import java.nio.file.Paths; jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-14- jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-15-public class OSUtils { jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-16- jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java:17: public static final boolean IS_WINDOWS = System.getProperty("os.name").toLowerCase().contains("win"); jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-18- jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-19- public static final boolean IS_CYGWIN = IS_WINDOWS jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-20- && System.getenv("PWD") != null jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-21- && System.getenv("PWD").startsWith("/"); -- jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-38- jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-39- public static final boolean IS_CONEMU = IS_WINDOWS jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-40- && System.getenv("ConEmuPID") != null; jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-41- jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java:42: public static final boolean IS_OSX = System.getProperty("os.name").toLowerCase().contains("mac"); jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java:43: public static final boolean IS_AIX = System.getProperty("os.name").equals("AIX"); jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java-44- -- jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java-349- case LINUX: return "Linux"; jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java-350- case MACOS: return "Mac OS X"; jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java-351- case AIX: return "AIX"; jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java-352- case WINDOWS: { jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java:353: String osName = System.getProperty("os.name"); jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java-354- if (osName.startsWith("Windows")) { jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java-355- // Use original value which is often more "complete" jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java-356- // E.g. "Windows Server 2012" jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java-357- return osName; -- jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java-148- } jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java-149- throw new FailedLoginException jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java-150- ("Failed in attempt to import the " + jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java-151- "underlying NT system identity information" + jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java:152: " on " + System.getProperty("os.name")); jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java-153- } -- jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java-128- succeeded = false; jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java-129- throw new FailedLoginException jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java-130- ("Failed in attempt to import " + jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java-131- "the underlying system identity information" + jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java:132: " on " + System.getProperty("os.name")); jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java-133- } -- jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java-83-class ZipFileSystem extends FileSystem { jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java-84- // statics jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java-85- @SuppressWarnings("removal") jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java-86- private static final boolean isWindows = AccessController.doPrivileged( jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java:87: (PrivilegedAction)()->System.getProperty("os.name") jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java-88- .startsWith("Windows")); jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java-89- private static final byte[] ROOTPATH = new byte[] { '/' }; jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java-90- private static final String PROPERTY_POSIX = "enablePosixFileAttributes"; jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java-91- private static final String PROPERTY_DEFAULT_OWNER = "defaultOwner"; Any idea why it is done so seldom in the codebase ? ZipFileSystem.java does it, but most other calls (see above) seems to omit / 'forget' it . Is there something about the other calls, that it is not needed there ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1702726371 From mbaesken at openjdk.org Fri Sep 1 13:26:19 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 1 Sep 2023 13:26:19 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v3] In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: <0-6yDafhaZaYBNIvY3bCXULClXqq2PgmsQi2TAA5p0M=.c857a125-8e2c-4ba6-bf2b-3bcee160d9db@github.com> > We run into some BackingStoreException: Couldn't get file lock. e.g. here : > > [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) > [JShell] ... 4 more > > The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: follow Martin's codestyle suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15308/files - new: https://git.openjdk.org/jdk/pull/15308/files/9230e1e3..d385dac1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15308&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15308&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15308.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15308/head:pull/15308 PR: https://git.openjdk.org/jdk/pull/15308 From mbaesken at openjdk.org Fri Sep 1 13:26:19 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 1 Sep 2023 13:26:19 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: On Fri, 1 Sep 2023 12:36:28 GMT, Matthias Baesken wrote: >> We run into some BackingStoreException: Couldn't get file lock. e.g. here : >> >> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) >> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) >> [JShell] ... 4 more >> >> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add for some errnos also the string Hi Martin, thanks for the review ! I did some small adjustments to follow your coding style suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1702741358 From alanb at openjdk.org Fri Sep 1 13:30:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Sep 2023 13:30:41 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: On Fri, 1 Sep 2023 13:10:19 GMT, Matthias Baesken wrote: > Hi Alan , Your assumption 'I assume the use of System.getProperty is problematic when running with a SM.' is most likely correct. You'll need to test with a SM that denies reading the system property to be sure. There are classes in many tool APIs (you've listed some) where this doesn't arise. In any case, I assume this lookup will go away once you replace this method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1702749867 From pminborg at openjdk.org Fri Sep 1 13:54:28 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 1 Sep 2023 13:54:28 GMT Subject: RFR: 8315454: Add an immutable BitSet [v2] In-Reply-To: References: Message-ID: > This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: > > PoolReader (6) > URLEncoder (1) - Updated in this PR > HtmlTree (2) > > More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. > > Initial benchmarks with the URLEncoder show encouraging results: > > > Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% > URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) Per Minborg has updated the pull request incrementally with three additional commits since the last revision: - Fix test - Remove unused imports - Convert into an internal API ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15530/files - new: https://git.openjdk.org/jdk/pull/15530/files/e4be1ff0..2cd9eebd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15530&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15530&range=00-01 Stats: 111 lines in 4 files changed: 59 ins; 47 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15530.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15530/head:pull/15530 PR: https://git.openjdk.org/jdk/pull/15530 From pminborg at openjdk.org Fri Sep 1 14:07:11 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 1 Sep 2023 14:07:11 GMT Subject: RFR: 8315454: Add a way to create an immutable snapshot of a BitSet [v3] In-Reply-To: References: Message-ID: > This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: > > PoolReader (6) > URLEncoder (1) - Updated in this PR > HtmlTree (2) > > More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. > > Initial benchmarks with the URLEncoder show encouraging results: > > > Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% > URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add comment on defensive copying ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15530/files - new: https://git.openjdk.org/jdk/pull/15530/files/2cd9eebd..c3977aa3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15530&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15530&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15530.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15530/head:pull/15530 PR: https://git.openjdk.org/jdk/pull/15530 From jpai at openjdk.org Fri Sep 1 15:01:38 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 1 Sep 2023 15:01:38 GMT Subject: RFR: 8233160: Add java.vendor.url.bug to list of recognized standard system properties In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 06:53:45 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8233160? > > It has been noted in https://bugs.openjdk.org/browse/JDK-8232753 that: > >> The java.vendor.url.bug property has been defined by every Sun/Oracle JDK going all the way back to JDK 5 (and possibly earlier; JDK 5 is the oldest release that I can still run on my development machine). Yet, it's never been specified. > > The OpenJDK builds too by default set a value for this system property. > > The commit in this PR updates the javadoc of `System.getProperties()` to include this system property in the list of specified properties. Additionally, the `test/jdk/java/lang/System/PropertyTest.java` test has been updated to verify that this property is indeed available in the Properties returned by `System.getProperites()`. > > I'll create a CSR shortly for this change. I asked for Mark's and Joe's inputs on this in the linked JBS issue https://bugs.openjdk.org/browse/JDK-8233160. Mark has suggested that we keep this `java.vendor.url.bug` system property non-optional and also not to add any expectations of the value for this property to be a parsable URL. Both of those inputs match with what is currently proposed in this PR. I'll go ahead and draft a CSR shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15504#issuecomment-1702893039 From dl at openjdk.org Fri Sep 1 15:04:32 2023 From: dl at openjdk.org (Doug Lea) Date: Fri, 1 Sep 2023 15:04:32 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v20] In-Reply-To: References: Message-ID: <0xAmdH1KR9bZucbBuyVg6fRzqPTv9exDifSXWY6mjuI=.8ca3963a-4a21-4b2c-8b35-bd66e1d9e8a8@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 64 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8288899 - Fix tests, undo workarounds - Avoid unwanted jtreg interrupts; undo unnecessary changes - Merge branch 'openjdk:master' into JDK-8288899 - Clear interrupts at top level - Conditionalize new tests - Isolate unexpected interrupt status issues - Ordering for termination triggering - Resync CloseTest - Merge branch 'openjdk:master' into JDK-8288899 - ... and 54 more: https://git.openjdk.org/jdk/compare/6c66a521...c40a3245 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14301/files - new: https://git.openjdk.org/jdk/pull/14301/files/53599566..c40a3245 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=18-19 Stats: 11417 lines in 274 files changed: 7432 ins; 1985 del; 2000 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 mbalao at openjdk.org Fri Sep 1 15:20:19 2023 From: mbalao at openjdk.org (Martin Balao) Date: Fri, 1 Sep 2023 15:20:19 GMT Subject: RFR: 8315487: Security Providers Filter Message-ID: In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR. ## ProvidersFilter ### Filter construction (parser) The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized. The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor. While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future. ### Filter (structure and behavior) A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the service matches it. Otherwise, the filter moves to the next rule in the sequence. Rules are made of 3 regular expressions, derived from a filter pattern: provider, service type and algorithm or alias. A service matches a rule when its provider, service type and algorithm or alias matches the corresponding regular expressions in the rule. When a rule is matched by a service, it casts a decision (represented by the ProvidersFilter::FilterDecision class) that has two values: an allow or deny result and a priority that depends on how early (or left, in filter string terms) the rule is positioned in relative terms. Priorities are used for services that have aliases, as a mechanism to disambiguate contradictory decision results depending on which alias or algorithm is evaluated. When a service with aliases is passed through a filter, independent evaluations are made for the algorithm and each alias. The decision with highest priority (lowest in absolute numbers) is finally effective. ### Filter decisions cache To accomplish the goal of maximizing performance, most services are passed through the Providers filter at registration time, when added with the java.security.Provider::putService or java.security.Provider::put APIs. While uncommon, providers may override java.security.Provider::getService or java.security.Provider::getServices APIs and return services that were never registered. In these cases, the service is evaluated against the Providers filter the first time used. Once a service is evaluated against the filter, the decision is stored in the private isAllowed Provider.Service class field. When authorizing further uses of the service, the value from this cache is read, instead of performing a new filter evaluation. If the service does not experience any change, such as gaining or losing an alias (only possible with the legacy API), the cached value remains valid. Otherwise, a new filter evaluation has to take place. For example, a service could have been not allowed but a new alias matches an authorization rule in the filter that flips the previous decision. The method Provider.Service::computeIsAllowed (that internally invokes ProvidersFilter::computeIsAllowed) can be used to force the recomputation of an authorization cached decision. The method ProvidersFilter::isAllowed, when filtering capabilities are enabled, tries to get the service authorization from the Provider.Service isAllowed field, and triggers a computation if not initialized. For this mechanism to work, the Provider.Service::getIsAllowed private method is exposed through SharedSecrets and accessed from ProvidersFilter. ### Filter checking idiom At every point in the JDK where any of Provider::getService or Provider::getServices APIs are invoked, a Providers filter check must be applied by calling ProvidersFilter.isAllowed(serviceInstance). It's assumed that serviceInstance is not null. The returned value indicates if the serviceInstance service is allowed or not. When a service is not allowed, the caller must discard it. The reason why we need to apply this checking pattern is because Provider::getService or Provider::getServices APIs may be overwritten by a provider to return unregistered services that were not evaluated against the filter before. If these APIs were not overwritten, the implementation will only return allowed services. ### Debugging the filter There are 3 mechanisms to debug a filter: 1 - Set the "java.security.debug" System property to "jca" and find filter-related messages prefixed by "ProvidersFilter". This debug output includes information about the filter construction (parsing) as well as evaluations of services against the filter. Note: the application has to trigger the ProvidersFilter class static initialization for this output to be generated, for example by invoking java.security.Security::getProviders. Example: java -Djava.security.debug=jca -Djdk.security.providers.filter="SunJCE.Cipher.AES" Main Filter construction messages: ProvidersFilter: Parsing: SunJCE.Cipher.AES ProvidersFilter: -------------------- ProvidersFilter: Rule parsed: SunJCE.Cipher.AES ProvidersFilter: * Provider: SunJCE (regexp: \QSunJCE\E) ProvidersFilter: * Service type: Cipher (regexp: \QCipher\E) ProvidersFilter: * Algorithm: AES (regexp: \QAES\E) ProvidersFilter: * Decision: ALLOW - priority: 0 ProvidersFilter: Filter: SunJCE.Cipher.AES; !* (DEFAULT) ProvidersFilter: -------------------- Filter evaluation messages: ProvidersFilter: Service filter query (Provider: SunJCE, Service type: Cipher, Algorithm: AES) ProvidersFilter: * Decision: ALLOW - priority: 0 ProvidersFilter: * Made by: SunJCE.Cipher.AES ProvidersFilter: -------------------- ProvidersFilter: The queried service has aliases. Checking them for a final decision... ProvidersFilter: -------------------- ProvidersFilter: Service filter query (Provider: SunJCE, Service type: Cipher, Algorithm: OID.2.16.840.1.101.3.4.1) ProvidersFilter: * Decision: DENY - priority: 1 ProvidersFilter: * Made by: !* (DEFAULT) ProvidersFilter: -------------------- ProvidersFilter: Service filter query (Provider: SunJCE, Service type: Cipher, Algorithm: 2.16.840.1.101.3.4.1) ProvidersFilter: * Decision: DENY - priority: 1 ProvidersFilter: * Made by: !* (DEFAULT) ProvidersFilter: -------------------- ProvidersFilter: Final decision based on AES algorithm: ALLOW - priority: 0 2 - Pass the -XshowSettings:security:providers JVM argument and check, for each statically installed security provider, which services are allowed and not allowed by the filter. Example: java -XshowSettings:security:providers -Djdk.security.providers.filter="SunJCE.Cipher.AES" -version Security provider static configuration: (in order of preference) ... ---------------------------------------- Provider name: SunJCE ... Provider services allowed: (type : algorithm) Cipher.AES aliases: [2.16.840.1.101.3.4.1, OID.2.16.840.1.101.3.4.1] Provider services NOT allowed: (type : algorithm) AlgorithmParameterGenerator.DiffieHellman aliases: [1.2.840.113549.1.3.1, DH, OID.1.2.840.113549.1.3.1] ... ---------------------------------------- ... 3 - When a filter cannot be constructed, the ProvidersFilter.ParserException exception includes the state of the filter at the time when the error occurred, and indicates which pattern could not be parsed. Example: java -XshowSettings:security:providers -Djdk.security.providers.filter="SunJCE.Cipher.AES; My Provider" Caused by: sun.security.jca.ProvidersFilter$Filter$ParserException: Only whitespace characters are valid after a pattern. Whitespaces that are part of a provider name, service type or algorithm must be escaped. * State: POST_PATTERN * Filter string: SunJCE.Cipher.AES; My Provider ---^--- ## ServicesMap Existing Provider::getService and Provider.getServices APIs were changed to return services that are allowed by the Providers filter only. In addition, a new Provider::getServicesNotAllowed method (exposed through the SharedSecrets mechanism) was introduced to obtain services that are not allowed by the Providers filter, for informational purposes only (see -XshowSettings:security:providers). These changes motivated an analysis of how services are stored internally in a Provider instance, and lead to the refactoring that will be explained in this section. ### Existing bugs and inconsistencies While analyzing the existing services map implementation, we categorized bugs found in 3 sets: 1) Concurrency bugs, 2) Serialization consistency bugs, and 3) Other bugs. While many of these bugs are related to corner cases that are unlikely to be triggered in real providers, others can potentially happen in highly concurrent scenarios and would be difficult to reproduce. #### 1 - Concurrency bugs 1.1 - A concurrent Provider::getServices call may remove services that are temporarily considered invalid because they are in the midst of an update. I.e. a provider added an alias but not the class name still, and a reader removes the service in between: Thread-1 (writer): Provider::put("Alg.Alias.MessageDigest.alias1", "alg1") ---> An invalid service is implicitly created Thread-2 (reader): Provider::getServices() ---> The invalid service is removed Thread-1 (writer): Provider::put("MessageDigest.alg1", "class1") ---> While the service is added again (valid, now), it won't have alias1. While the situation sounds unlikely for a regular service registration, it is possible when deserializing Providers as the order in which Property map entries are visited is not guaranteed. This scenario was not possible before JDK-8276660 because readers only removed invalid entries from legacyMap, but not from legacyStrings. As a result, invalid services could land in legacyMap without losing data after they become valid. See a reference to the JDK-8276660 removal here [1]. We have developed the ServicesConsistency::testInvalidGetServicesRemoval test to reflect this case. Notice that the fact that legacyMap is a ConcurrentHashMap instance does not prevent this bug from happening, as the problem is between non-atomic and non-synchronized writes. 1.2 - This bug is similar to 1.1 but occurs in Provider::getService [2], and is reflected in the test ServicesConsistency::testInvalidGetServiceRemoval. 1.3 - When signaling legacyChanged = false after recomputing the services set here [3], a concurrent legacyMap update that right before set legacyChanged = true [4] [5] would be missed. This was introduced by JDK-8276660 because, previously, legacyChanged = false was done in ensureLegacyParsed and this method was called in a synchronized getService block. Notice here that making legacyChanged volatile did not prevent this issue, as the problem is that publishing the new computed set and resetting the legacyChanged variable is not an atomic operation and a new update could have happened in between. We think that this type of problem can be solved in a lock-free way with a pattern such as the one proposed in ServicesMap::getServicesSet, that includes a double compare and exchange with a placeholder while computing the set. 1.4 - In operations such as Provider::implReplaceAll, there is a window in which all services look gone for readers [6] and this may cause spurious NoSuchAlgorithmException exceptions. Before JDK-8276660 the operation was seen as atomic by readers. The replaceAll change in the Properties map was made on legacyStrings by writers but only visible after readers impacted changes under a synchronized block. We think that replaceAll and putAll should be atomic for readers. In particular, putAll would be the legacy API mechanism to ensure that readers see services only when they have all their attributes added, and there is no risk of obtaining a service with half of them. See a test that checks an atomic replaceAll behavior in ServicesConsistency::testReplaceAllIsAtomic and a test that checks a putAll atomic behavior in ServicesConsistency::testPutAllIsAtomic. 1.5 - When a reader obtains a service from the legacyMap, Service::newInstance or Service::supportsParameter may be invoked and cached values such as classCache, constructorCache, hasKeyAttributes, supportedFormats and supportedClasses set. If there are further changes to the service (i.e.: new attributes added), cached values are never invalidated and there is a single service instance. As a result, the service information becomes inconsistent and the new attributes are missed, even for new readers. This did not happen before JDK-8276660 because ensureLegacyParsed started with a clear legacyMap and new Service instances (with uninitialized cache fields) were added. This bug is reflected in ServicesConsistency::testInvalidCachedClass, ServicesConsistency::testInvalidCachedHasKeyAttributes and ServicesConsistency::testInvalidCachedSupportedKeyFormats tests. #### 2 - Serialization consistency bugs This type of bugs make a deserialized Provider to have different services (class names, aliases and attributes) than the original instance. What they have in common is one or more of the following traits: 1) lack of synchronization between the Properties map and the actual inner services map, 2) an incorrect assumption that the Properties map is visited, while deserializing, in the same order in which entries were originally added, or 3) an inconsistent collision behavior between the Provider::put and Provider::putService APIs. We will show some examples that, while unrealistic, serve for the purpose of illustrating the aforementioned inconsistencies: 2.1 - Case-sensitive entries Ordered list of actions: put("MessageDigest.alg", "class1") put("MessageDigest.ALG", "class2") The previous list of actions creates a single Service instance that has "class2" as its class name. In the Properties map, however, both entries are present. List of actions in the order that they are executed while deserializing the provider: put("MessageDigest.ALG", "class2") put("MessageDigest.alg", "class1") The created Service instance, after deserialization, has "class1" as its class name. This case is reflected in the ServicesConsistency::testSerializationClassnameConsistency test. 2.2 - Entries by alias Ordered list of actions: put("MessageDigest.alg", "class1") put("Alg.Alias.MessageDigest.alias", "alg") put("Alg.Alias.MessageDigest.alias2", "alias") The previous list of actions creates a single Service instance that has "alg" as its algorithm, and "alias" and "alias2" as its aliases. List of actions in the order that they are executed while deserializing the provider: put("Alg.Alias.MessageDigest.alias2", "alias") put("Alg.Alias.MessageDigest.alias", "alg") put("MessageDigest.alg", "class1") After deserialization there will be two Service instances: one has "alias" as its algorithm and "alias2" as its alias, and the other has "alg" as its algorithm and "alias" as its alias. The former instance is invalid and reachable by "alias2" only, and the latter is valid and reachable by "alg" or "alias". 2.3 - Algorithm case-insensitive collision between Provider::putService and Provider::put Ordered list of actions: put("MessageDigest.ALG", "class1") putService(new Service(provider, "MessageDigest", "alg", "class2", null, null)) The previous list of actions creates two Service instances, from which the one using "class2" as its class name is visible. However, the Properties map has entries for both services. List of actions in the order that they are executed while deserializing the provider: put("MessageDigest.alg", "class2") put("MessageDigest.ALG", "class1") After deserialization, only the Service instance that has "class1" as its class name is available. This case is related to the ServicesConsistency::testCurrentAPIServicesOverride test. 2.4 - Alias collision between Provider::putService and Provider::put putService(new Service(provider, "MessageDigest", "alg1", "class1", List.of("alias"), null)) put("MessageDigest.alg2", "class2") put("Alg.Alias.MessageDigest.alias", "alg2") The previous list of actions creates two service instances, from which the one using "class1" as its class name is visible by "alias". However, the Properties map has the entry "Alg.Alias.MessageDigest.alias" associated with the service instance using "class2" as its class name. List of actions executed while deserializing the provider (in any order): put("MessageDigest.alg1", "class1") put("MessageDigest.alg2", "class2") put("Alg.Alias.MessageDigest.alias", "alg2") After deserialization, the Service instance using "class2" as its class name is the one identified by the alias "alias". This same inconsistency may occur with the algorithm instead of the alias. This case is related to the ServicesConsistency::legacyAPIServicesOverride test. 2.5 - Overwrites of algorithms with aliases Ordered list of actions: put("MessageDigest.alg1", "class1") put("Alg.Alias.MessageDigest.alias1", "alg1") put("MessageDigest.alg2", "class2") put("Alg.Alias.MessageDigest.alg1", "alg2") The previous list of actions creates two service instances, one that has "alg1" as its algorithm, "class1" as its class name and "alias1" as its alias, and the other that has "alg2" as its algorithm, "class2" as its class name and "alg1" as its alias. List of actions in the order that they are executed while deserializing the provider: put("MessageDigest.alg2", "class2") put("Alg.Alias.MessageDigest.alg1", "alg2") put("MessageDigest.alg1", "class1") put("Alg.Alias.MessageDigest.alias1", "alg1") After deserialization, a single Service instance is created. This instance has "alg2" as its algorithm, "class1" as its class name, and "alg1" and "alias1" as its aliases. This case is related to the ServicesConsistency::testLegacyAPIAliasCannotBeAlgorithm test. #### 3 - Other bugs 3.1 - Invalid services (without a class name) can be returned in Provider::getService, even when they are removed from the legacyMap [7]. This case is reflected in the ServicesConsistency::testInvalidServiceNotReturned test. 3.2 - Methods Provider::implMerge and Provider::implCompute pass a "null" value as the 2nd parameter to Provider::parseLegacy and a remove action [8]. In the case of an alias, Provider::parseLegacy will throw a NullPointerException here [9]. This issue has been introduced by JDK-8276660, and is reflected in the tests ServicesConsistency::testComputeDoesNotThrowNPE and ServicesConsistency::testMergeDoesNotThrowNPE. Note: we might be overlooking more bugs, as we decided to go with a new implementation at this point. ### Proposal We replaced the mechanism through which Service instances are organized inside a Provider, while maintaining the existing APIs to store and fetch services. These APIs are internally called Legacy and Current. The solution was designed to follow the principles of avoiding bottlenecks for service map readers (lock-free, thread-safe), ensuring consistency after Providers deserialization, ensuring consistency between the Provider's properties map and the actual services, enforcing consistency between the Legacy and Current APIs, and maintaining previous behavior to the maximum extent possible. What follows is a description of the most relevant design choices: 1 - Properties map synchronization: what you see on the Properties map is what you get from the internal services map Adding, modifying or removing a service has a direct or indirect impact on the Properties map to enforce consistency. For example, adding an uppercase entry may overwrite a previous lowercase one. While this behavior is different from a regular Properties structure, having both entries would break synchronization with the internal services map (which is case insensitive) and is problematic for serialization. Other cases, such as adding entries by aliases, are also handled and canonicalized. 2 - The Current API (Provider::putService) has preference over the Legacy API (Provider::put). We kept the preference of Provider::getService and Provider::getServices methods for Current API services over Legacy API counterparts. However, the internal map is now unified and Legacy services may be overwritten ?notice that the opposite is not possible?. This was redesigned considering that there is a single Properties map, and we aim to keep it aligned to the internal services map. For expected behavior between the Legacy and Current APIs, we suggest looking at the ServicesConsistency::testLegacyAPIServicesOverride and ServicesConsistency::testCurrentAPIServicesOverride tests. 3 - Copy-on-write strategy for Legacy API service changes We implemented a copy-on-write strategy that reminds of the one before JDK-8276660 but has a key difference: the new implementation is lock-free and faster from a service readers point of view. This strategy makes it possible to have service consistency in multi-threaded scenarios, and fix many of the concurrency bugs previously described. In terms of time consistency, we do not enforce that constraint between different services obtained from Provider::getServices. In other words, the Set returned may have an old version of service A and a new version of service B, even when the change to service A was applied first. We consider that it is not worth paying a synchronization cost for this type of consistency. Notice that Current API services do not require this approach because they are immutable: once added, they cannot be changed. 4 - Lock-free Provider::getServices The Provider::getServices method is optimized for service readers with a cached set and a lock-free implementation. ## SunNativeProvider Changes were introduced to make the SunNativeProvider security provider use the Provider::putService API to register services, instead of the legacy Provider::putAll. This was the only security provider in OpenJDK using a non-Provider::putService API. While this change does not have any observable implications, it is in the interest of a better code ?and sets a better example? to align it with the other OpenJDK security providers. In our assessment, these are the OpenJDK providers using the Providers::putService API: SunJCE, SunPKCS11, SunRsaSign, SunEC, SUN, SunJSSE, SunMSCAPI, XMLDSigRI, JdkLDAP, JdkSASL, SunJGSS, SunPCSC, Apple and SunJarVerification. ## Testing As part of our testing, we observed no regressions in the following test categories: * jdk:tier1 * jdk/java/security * jdk/sun/security Additionally, we introduced the following new regression tests: * jdk/sun/security/provider/ProvidersFilterTest.java * jdk/java/security/Provider/ServicesConsistency.java Finally, we extended the following tests: * jdk/tools/launcher/Settings.java This contribution is co-authored by Francisco Ferrari and Martin Balao. -- [1] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1332 [2] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1289 [3] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1340 [4] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1145 [5] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1181 [6] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L976 [7] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1285-L1301 [8] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L999-L1016 [9] - https://github.com/openjdk/jdk/blob/jdk-20-ga/src/java.base/share/classes/java/security/Provider.java#L1146 ------------- Commit messages: - 8315487: Security Providers Filter Changes: https://git.openjdk.org/jdk/pull/15539/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315487 Stats: 4600 lines in 24 files changed: 4029 ins; 323 del; 248 mod Patch: https://git.openjdk.org/jdk/pull/15539.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539 PR: https://git.openjdk.org/jdk/pull/15539 From duke at openjdk.org Fri Sep 1 15:41:01 2023 From: duke at openjdk.org (Qing Xiao) Date: Fri, 1 Sep 2023 15:41:01 GMT Subject: RFR: 8315444: Convert test/jdk/tools to Classfile API Message-ID: /test/jdk/tools/lib/tests/JImageValidator.java, tests in /test/jdk/tools/jlink and /test/jdk/tools/jimage use on com.sun.tools.classfile and should be converted to Classfile API. ------------- Commit messages: - migrate /test/jdk/tools/lib/tests/JImageValidator.java and tests in /test/jdk/tools/jlink and /test/jdk/tools/jimage use Classfile API Changes: https://git.openjdk.org/jdk/pull/15529/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15529&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315444 Stats: 168 lines in 23 files changed: 111 ins; 15 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/15529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15529/head:pull/15529 PR: https://git.openjdk.org/jdk/pull/15529 From asotona at openjdk.org Fri Sep 1 15:41:01 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 1 Sep 2023 15:41:01 GMT Subject: RFR: 8315444: Convert test/jdk/tools to Classfile API In-Reply-To: References: Message-ID: <5NriqBvXRcYPmM7oevCaKdXMQTyKELI5fdjGcm1klLg=.fd9bb5c3-ac94-4b00-aca5-1a5a0cad4e24@github.com> On Fri, 1 Sep 2023 08:14:26 GMT, Qing Xiao wrote: > /test/jdk/tools/lib/tests/JImageValidator.java, tests in /test/jdk/tools/jlink and /test/jdk/tools/jimage use on com.sun.tools.classfile and should be converted to Classfile API. It looks good, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15529#issuecomment-1702761805 From mchung at openjdk.org Fri Sep 1 16:55:50 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 1 Sep 2023 16:55:50 GMT Subject: RFR: 8315383: jlink SystemModulesPlugin incorrectly parses the options [v2] In-Reply-To: References: <8JLvIydPLtNKzBHiCLLM6Q4RbScQLPvShTSw_VtBn68=.ba04e37c-3ed6-46e0-be78-acee7ef3711f@github.com> Message-ID: On Wed, 30 Aug 2023 23:39:31 GMT, Oliver Kopp wrote: >> Fixes https://bugs.openjdk.org/browse/JDK-8315383 > > Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete imports sure, I can help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15495#issuecomment-1703046225 From rriggs at openjdk.org Fri Sep 1 17:58:46 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Sep 2023 17:58:46 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. As @AlanBateman said, the purpose of halt is to immediately exit. If there are concerns about use of System.halt() a static scan of the class files will identify its use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1703133971 From duke at openjdk.org Fri Sep 1 18:39:18 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 1 Sep 2023 18:39:18 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v16] In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: > Optimization for: > Integer.toString > Long.toString > StringBuilder#append(int) > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.Integers.toString*" > make test TEST="micro:java.lang.Longs.toString*" > make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op > -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op > -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) > +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) > +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) > > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op > -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) > +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op > > +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) > > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op > -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op > -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ? 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... ??? has updated the pull request incrementally with 736 additional commits since the last revision: - 8303427: Fixpath confused if unix root contains "/jdk" Reviewed-by: mikael - 8314319: LogCompilation doesn't reset lateInlining when it encounters a failure. Reviewed-by: ecaspole, kvn - 8258970: Disabled JPasswordField foreground color is wrong with GTK LAF Reviewed-by: tr, dnguyen, psadhukhan - 8315195: RISC-V: Update hwprobe query for new extensions Reviewed-by: fyang, fjiang, luhenry - 8315446: G1: Remove unused G1AllocRegion::attempt_allocation Reviewed-by: iwalulya, tschatzl - 8315098: Improve URLEncodeDecode microbenchmark Reviewed-by: ecaspole, dfuchs - 8315321: [aix] os::attempt_reserve_memory_at must map at the requested address or fail Reviewed-by: mdoerr - 8315436: HttpsServer does not send TLS alerts Reviewed-by: dfuchs, michaelm - 8315069: Relativize extended_sp in interpreter frames Reviewed-by: haosun, aph, fyang - 8313983: jmod create --target-platform should replace existing ModuleTarget attribute Reviewed-by: alanb, mchung - ... and 726 more: https://git.openjdk.org/jdk/compare/cf2f8395...a635f903 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14699/files - new: https://git.openjdk.org/jdk/pull/14699/files/cf2f8395..a635f903 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=14-15 Stats: 156684 lines in 3194 files changed: 65663 ins; 71956 del; 19065 mod Patch: https://git.openjdk.org/jdk/pull/14699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699 PR: https://git.openjdk.org/jdk/pull/14699 From duke at openjdk.org Fri Sep 1 18:40:55 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 1 Sep 2023 18:40:55 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v17] In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: > Optimization for: > Integer.toString > Long.toString > StringBuilder#append(int) > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.Integers.toString*" > make test TEST="micro:java.lang.Longs.toString*" > make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op > -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op > -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) > +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) > +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) > > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op > -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) > +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op > > +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) > > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op > -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op > -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ? 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - remove unused import - UTF16 & Latin1 use same lookup table - assert bounds check - Integer/Long toString test against compact strings Co-authored-by: liach - Adapt endian in pack Co-authored-by: liach - use upper case for static final field - private static final Unsafe - code format - simplify code - format code & comment - ... and 6 more: https://git.openjdk.org/jdk/compare/2f7c65ec...0d149fa9 ------------- Changes: https://git.openjdk.org/jdk/pull/14699/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=16 Stats: 175 lines in 5 files changed: 107 ins; 20 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/14699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699 PR: https://git.openjdk.org/jdk/pull/14699 From duke at openjdk.org Fri Sep 1 18:44:13 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 1 Sep 2023 18:44:13 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v4] In-Reply-To: References: Message-ID: > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.StringUpperLower.*" > > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark Mode Cnt Score Error Units (baseline) > -StringUpperLower.lowerToLower avgt 15 27.180 ? 0.017 ns/op > -StringUpperLower.lowerToUpper avgt 15 47.196 ? 0.066 ns/op > -StringUpperLower.mixedToLower avgt 15 32.307 ? 0.072 ns/op > -StringUpperLower.mixedToUpper avgt 15 44.005 ? 0.414 ns/op > -StringUpperLower.upperToLower avgt 15 32.310 ? 0.033 ns/op > -StringUpperLower.upperToUpper avgt 15 42.053 ? 0.341 ns/op > > +Benchmark Mode Cnt Score Error Units (Update 01) > +StringUpperLower.lowerToLower avgt 15 16.964 ? 0.021 ns/op (+60.96%) > +StringUpperLower.lowerToUpper avgt 15 46.491 ? 0.036 ns/op (+1.51%) > +StringUpperLower.mixedToLower avgt 15 35.947 ? 0.254 ns/op (-10.12%) > +StringUpperLower.mixedToUpper avgt 15 41.976 ? 0.326 ns/op (+4.83%) > +StringUpperLower.upperToLower avgt 15 33.466 ? 4.036 ns/op (-3.45%) > +StringUpperLower.upperToUpper avgt 15 17.446 ? 1.036 ns/op (+141.04%) > > +Benchmark Mode Cnt Score Error Units (Update 00) > +StringUpperLower.lowerToLower avgt 15 16.976 ? 0.043 ns/op (+60.160) > +StringUpperLower.lowerToUpper avgt 15 46.373 ? 0.086 ns/op (+1.77%) > +StringUpperLower.mixedToLower avgt 15 32.018 ? 0.061 ns/op (+0.9%) > +StringUpperLower.mixedToUpper avgt 15 42.019 ? 0.473 ns/op (+4.72%) > +StringUpperLower.upperToLower avgt 15 32.052 ? 0.051 ns/op (+0.8%) > +StringUpperLower.upperToUpper avgt 15 16.978 ? 0.190 ns/op (+147.69%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark Mode Cnt Score Error Units (baseline) > -StringUpperLower.lowerToLower avgt 15 22.164 ? 0.021 ns/op > -StringUpperLower.lowerToUpper avgt 15 46.113 ? 0.047 ns/op > -StringUpperLower.mixedToLower avgt 15 28.501 ? 0.037 ns/op > -StringUpperLower.mixedToUpper avgt 15 38.782 ? 0.038 ns/op > -StringUpperLower.upperToLower avgt 15 28.625 ? 0.162 ns/op > -StringUpperLower.upperToUpper avgt 15 27.960 ? 0.038 ns/op > > +Benchmark Mode Cnt Score Error Units (Update 01) > +StringUpperLower.lowerToLo... ??? has updated the pull request incrementally with one additional commit since the last revision: use hex literal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14751/files - new: https://git.openjdk.org/jdk/pull/14751/files/bc03c99a..a5ace579 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14751&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14751&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14751/head:pull/14751 PR: https://git.openjdk.org/jdk/pull/14751 From duke at openjdk.org Fri Sep 1 19:55:51 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 1 Sep 2023 19:55:51 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v3] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 11:39:57 GMT, Claes Redestad wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> add method CharacterDataLatin1#isLowerCaseEx > > src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 94: > >> 92: >> 93: boolean isLowerCaseEx(int ch) { >> 94: return ch >= 'a' && (ch <= 'z' || ch == 181 || (ch >= 223 && ch != 247)); > > What is the contract for this? Specifically there are two special superscripte codepoints (170 and 186) which are lower-case (`Character.isLowerCase(170) => true`) but doesn't have an upper-case (`Character.toUpperCase(170) => 170`). It seems reasonable to exclude them if only used for operations like toUpper/toLower (since they won't change), but it should be spelled out to avoid surprises. > > For consistency I think we should use hex literals in this file, e.g. `0xDF` instead of `223` The current implementation of the isLowerCaseEx method and the previous implementation "cp != CharacterDataLatin1.instance.toUpperCaseEx(cp)" The result is exactly the same. The code below compares all numbers in [-128, 128] import sun.misc.Unsafe; import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; import java.lang.reflect.Field; import java.nio.charset.StandardCharsets; import static com.alibaba.fastjson2.util.JDKUtils.UNSAFE; public class CharacterDataLatin1Test { public static void main(String[] args) throws Throwable { for (int i = Byte.MIN_VALUE; i <= Byte.MAX_VALUE; ++i) { byte b = (byte) i; int cp = b & 0xff; boolean r0 = cp != toUpperCaseEx(cp); boolean r1 = isLowerCaseEx(cp); if (r0) { System.out.println(cp + "\t0x" + Integer.toHexString(cp) + "\t" + new String(new byte[] {b}, StandardCharsets.ISO_8859_1)); } if (r0 != r1) { System.out.println("error " + i); } } } static boolean isLowerCaseEx(int ch) { return ch >= 'a' && (ch <= 'z' || ch == 0xb5 || (ch >= 0xdf && ch != 0xf7)); } static int toUpperCaseEx(int cp) throws Throwable { Field theUnsafeField = Unsafe.class.getDeclaredField("theUnsafe"); theUnsafeField.setAccessible(true); Unsafe unsafe = (Unsafe) theUnsafeField.get(null); Class charbinClass = Class.forName("java.lang.CharacterDataLatin1"); Field field = charbinClass.getDeclaredField("instance"); long fieldOffset = unsafe.staticFieldOffset(field); Object instance = unsafe.getObject(charbinClass, fieldOffset); Class lookupClass = MethodHandles.Lookup.class; Field implLookup = lookupClass.getDeclaredField("IMPL_LOOKUP"); MethodHandles.Lookup trustedLookup = (MethodHandles.Lookup) unsafe.getObject(lookupClass, UNSAFE.staticFieldOffset(implLookup)); MethodHandles.lookup(); MethodHandle toLowerCase = trustedLookup .findVirtual(charbinClass, "toUpperCaseEx", MethodType.methodType(int.class, int.class)); return (Integer) toLowerCase.invoke(instance, cp); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1313453795 From jlu at openjdk.org Fri Sep 1 19:56:28 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 1 Sep 2023 19:56:28 GMT Subject: RFR: 8314604: j.text.DecimalFormat behavior regarding patterns is not clear [v3] In-Reply-To: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com> References: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com> Message-ID: <8n5OUDN8DPqM6SGQg2juPxWFLyZe6AYd51ZzIFcAtqQ=.7343d889-3a68-49ba-9ec0-f4725bcb7a53@github.com> > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314607) which clarifies the behavior of patterns in regards to the max integer digits in j.text.DecimalFormat. > > The current specification (of `applyPattern`) states that patterns do not set the value of max integer digits. This is incorrect, these methods/constructors do set a value for the max integer digits. If the pattern is in scientific notation, the max integer digits value is derived from the pattern. Otherwise, the pattern is ignored, and the limit is set to `Integer.MAX_VALUE`. > > See below, > > DecimalFormat df = new DecimalFormat(); > df.applyPattern("000.000E0"); > df.getMaximumIntegerDigits(); // ==> 3 > df.applyPattern("000.000"); > df.getMaximumIntegerDigits(); // ==> 2147483647 > > DecimalFormat df = new DecimalFormat("000.000"); > df.getMaximumIntegerDigits(); // ==> 2147483647 > DecimalFormat df = new DecimalFormat("000.000E0"); > df.getMaximumIntegerDigits(); // ==> 3 > > > Method descriptions should be fixed, and the relevant constructors need to mention the behavior as well. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Reflect CSR comment, use anchor and reference - Merge branch 'master' into JDK-8314604 - Reflect review comments: Non sci notation first. Link to Scientific Notation section - Include constructors - Re-clarify spec - Init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15349/files - new: https://git.openjdk.org/jdk/pull/15349/files/93b0053e..258ce6d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15349&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15349&range=01-02 Stats: 16482 lines in 501 files changed: 11217 ins; 2724 del; 2541 mod Patch: https://git.openjdk.org/jdk/pull/15349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15349/head:pull/15349 PR: https://git.openjdk.org/jdk/pull/15349 From jlu at openjdk.org Fri Sep 1 19:56:53 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 1 Sep 2023 19:56:53 GMT Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for j.text.Format classes [v2] In-Reply-To: References: Message-ID: > Please review this PR 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`). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Reflect review comments: Make implementers aware of default classIdentity notion, generalize all hashcodes/equals, adjust hashCode spec to be more accurate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15459/files - new: https://git.openjdk.org/jdk/pull/15459/files/84bd4708..3e2d6745 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15459&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15459&range=00-01 Stats: 58 lines in 9 files changed: 29 ins; 4 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/15459.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15459/head:pull/15459 PR: https://git.openjdk.org/jdk/pull/15459 From duke at openjdk.org Fri Sep 1 20:08:40 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 1 Sep 2023 20:08:40 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v3] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 11:45:31 GMT, Claes Redestad wrote: > I think this overall looks reasonable, but I think a more thorough proof / test would help to build confidence that all these changes are semantically neutral. > > The `isLowerCaseEx` needs to explain why two lower-case codepoints are omitted (perhaps this should be `hasUpperCase`?) String str1 = new String(new byte[]{(byte) 0xb5}, StandardCharsets.ISO_8859_1); String str2 = new String(new byte[]{(byte) 0xdf}, StandardCharsets.ISO_8859_1); System.out.println(str1 + "\t" + str1.toUpperCase()); System.out.println(str2 + "\t" + str2.toUpperCase()); result : ? ? ? SS 0xb5 and 0xdf call toUpperCaseEx return and input are different, these two codepoints are to ensure that the behavior has not changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1703265488 From naoto at openjdk.org Fri Sep 1 22:10:41 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 1 Sep 2023 22:10:41 GMT Subject: RFR: 8314604: j.text.DecimalFormat behavior regarding patterns is not clear [v3] In-Reply-To: <8n5OUDN8DPqM6SGQg2juPxWFLyZe6AYd51ZzIFcAtqQ=.7343d889-3a68-49ba-9ec0-f4725bcb7a53@github.com> References: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com> <8n5OUDN8DPqM6SGQg2juPxWFLyZe6AYd51ZzIFcAtqQ=.7343d889-3a68-49ba-9ec0-f4725bcb7a53@github.com> Message-ID: On Fri, 1 Sep 2023 19:56:28 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314607) which clarifies the behavior of patterns in regards to the max integer digits in j.text.DecimalFormat. >> >> The current specification (of `applyPattern`) states that patterns do not set the value of max integer digits. This is incorrect, these methods/constructors do set a value for the max integer digits. If the pattern is in scientific notation, the max integer digits value is derived from the pattern. Otherwise, the pattern is ignored, and the limit is set to `Integer.MAX_VALUE`. >> >> See below, >> >> DecimalFormat df = new DecimalFormat(); >> df.applyPattern("000.000E0"); >> df.getMaximumIntegerDigits(); // ==> 3 >> df.applyPattern("000.000"); >> df.getMaximumIntegerDigits(); // ==> 2147483647 >> >> DecimalFormat df = new DecimalFormat("000.000"); >> df.getMaximumIntegerDigits(); // ==> 2147483647 >> DecimalFormat df = new DecimalFormat("000.000E0"); >> df.getMaximumIntegerDigits(); // ==> 3 >> >> >> Method descriptions should be fixed, and the relevant constructors need to mention the behavior as well. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Reflect CSR comment, use anchor and reference > - Merge branch 'master' into JDK-8314604 > - Reflect review comments: Non sci notation first. Link to Scientific Notation section > - Include constructors > - Re-clarify spec > - Init Update looks good ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15349#pullrequestreview-1607712190 From naoto at openjdk.org Fri Sep 1 22:16:39 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 1 Sep 2023 22:16:39 GMT Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for j.text.Format classes [v2] In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 19:56:53 GMT, Justin Lu wrote: >> Please review this PR 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`). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Reflect review comments: Make implementers aware of default classIdentity notion, generalize all hashcodes/equals, adjust hashCode spec to be more accurate src/java.base/share/classes/java/text/ChoiceFormat.java line 521: > 519: * > 520: * @implNote Implementers should be aware that the default implementation does an > 521: * equality check using {@code getClass} rather than {@code instanceOf} when Since `instanceof` is a Java keyword, I'd expect it not to be camel-cased. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15459#discussion_r1313583508 From jlu at openjdk.org Fri Sep 1 22:17:00 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 1 Sep 2023 22:17:00 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v2] In-Reply-To: References: Message-ID: > Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern. > > `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified. > > The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor. > > The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html Justin Lu 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 and resolve conflicts - Include Unicode sequence in pattern - Drop throws tag, that change can go to JDK8314925 - Clarify ? - Adjust pattern definition - Remove leftover comments - Revert the example changes to focus on the more important changes - Adjust wording of getter methods - Init ------------- Changes: https://git.openjdk.org/jdk/pull/15392/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=01 Stats: 64 lines in 1 file changed: 42 ins; 7 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/15392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15392/head:pull/15392 PR: https://git.openjdk.org/jdk/pull/15392 From jlu at openjdk.org Fri Sep 1 22:26:00 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 1 Sep 2023 22:26:00 GMT Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for j.text.Format classes [v3] In-Reply-To: References: Message-ID: > Please review this PR 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`). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: instanceof should not be camel case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15459/files - new: https://git.openjdk.org/jdk/pull/15459/files/3e2d6745..e322412c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15459&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15459&range=01-02 Stats: 9 lines in 9 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/15459.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15459/head:pull/15459 PR: https://git.openjdk.org/jdk/pull/15459 From naoto at openjdk.org Fri Sep 1 22:38:38 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 1 Sep 2023 22:38:38 GMT Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for j.text.Format classes [v3] In-Reply-To: References: Message-ID: <25miT-IHWm5PmEEcdNZ_4Y6JmwXqbo6e3-3IJYgAF4M=.8b079265-15c8-42ad-ab47-70ef0e8bd5a2@github.com> On Fri, 1 Sep 2023 22:26:00 GMT, Justin Lu wrote: >> Please review this PR 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`). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > instanceof should not be camel case Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15459#pullrequestreview-1607727326 From jlu at openjdk.org Fri Sep 1 23:18:51 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 1 Sep 2023 23:18:51 GMT Subject: RFR: 8315558: Undocumented exceptions in java.text.StringCharacterIterator Message-ID: Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315558) which is a conformance change to document some exceptions in the specification of java.text.StringCharacterIterator. ------------- Commit messages: - copyright year - init Changes: https://git.openjdk.org/jdk/pull/15547/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15547&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315558 Stats: 26 lines in 1 file changed: 14 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15547/head:pull/15547 PR: https://git.openjdk.org/jdk/pull/15547 From alanb at openjdk.org Sat Sep 2 09:04:37 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 2 Sep 2023 09:04:37 GMT Subject: RFR: 8315558: Undocumented exceptions in java.text.StringCharacterIterator In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 23:12:28 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315558) which is a conformance change to document some exceptions in the specification of java.text.StringCharacterIterator. @justin-curtis-lu You are correct that it needs a CSR as it is specifying exceptions that weren't previously specified. For the PR you'll need to link it to JDK-8315410, then use "/csr" to add the "csr" label. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15547#issuecomment-1703770188 From alanb at openjdk.org Sat Sep 2 09:23:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 2 Sep 2023 09:23:36 GMT Subject: RFR: 8306632: Add a JDK Property for specifying DTD support In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 18:41:48 GMT, Joe Wang wrote: > Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to specify how DTDs are handled. This property is uniformly supported across the JDK XML libraries. It complements, rather than replaces, the existing properties that are supportDTD for StAX and disallow-doctype-decl for DOM and SAX processors, which means the later will continue to work as they were and that if they are set, the new property will have no effect. Applications that use the existing properties continue to work as expected. > > This patch continues the path made previously with Xalan and XPath in which functions were moved into the jdk/xml classes. Similar changes are now made with the Xerces and XML classes, consolidating functions into the jdk/xml classes, reducing duplicate code for easier future maintenance. > > Tests: new tests are added to cover the various processors. > Existing tests pass. Only one was updated due to the change to the property impl. I think you've got this to a good place and brings uniformity to configuring how all the processors deal with DTDs. The proposal in the CSR is approved now so hopefully you'll get Reviewer cycles to help move forward on this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15075#issuecomment-1703776120 From dl at openjdk.org Sat Sep 2 11:17:20 2023 From: dl at openjdk.org (Doug Lea) Date: Sat, 2 Sep 2023 11:17:20 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v21] 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: Ignore more stray interrupts by test harness ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14301/files - new: https://git.openjdk.org/jdk/pull/14301/files/c40a3245..b35efb07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=19-20 Stats: 15 lines in 2 files changed: 8 ins; 0 del; 7 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 john.r.rose at oracle.com Sat Sep 2 16:38:33 2023 From: john.r.rose at oracle.com (John Rose) Date: Sat, 02 Sep 2023 09:38:33 -0700 Subject: RFR: 8315454: Add an immutable BitSet In-Reply-To: References: <28MB4IVOTMVjG491Gv640fwFJ2iNpHPzBhygkxuZ63E=.7ac764f5-d497-4603-b8c3-f8027f29503e@github.com> Message-ID: On 1 Sep 2023, at 2:38, Maurizio Cimadamore wrote: > On Fri, 1 Sep 2023 09:07:34 GMT, Per Minborg wrote: > >>> Maybe it would make sense to start with a JDK-internal variant before exploring potential public API? >> >> This is certainly one alternative. > > When looking at this I thought about that too. It seems like the particular case where this optimization is applicable is very specific, and I'm on the fence as to whether this deserves a public API. At the same time, there might be near-misses that could be difficult to address once the API is set in stone. I'd suggest to let it bake (inside the JDK) for some time, and later on decide whether it should be exposed as a public API. > > All that said, the idea of exposing a fast predicate over an immutable snapshot is very cute and clever :-) There is a related API I call Classifier which takes a List l and returns an immutable IntFunction, where the function works like x->l.indexOf(x). The reason it might deserve (someday) to be its own API is that the factory for a classifier might be allowed to do significant work to create an optimized instruction sequence for classifying its inputs. The literature of perfect hash functions would apply in many cases, and the classifier spun up for some particular list might operate in O(1) time. The reason I started thinking about such things was considering the optimization of switches (say, over strings or other values) and the optimization of RE character classes. Perfect hashing applies in both cases, but the heuristic algorithms should be hidden behind an API, and Classifier is what came up for me as the centerpiece. (That plus classifier factories on various kinds of lists and arrays and other sequences or sets.) ? John From joehw at openjdk.org Sun Sep 3 05:56:57 2023 From: joehw at openjdk.org (Joe Wang) Date: Sun, 3 Sep 2023 05:56:57 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 16:51:49 GMT, Naoto Sato wrote: >> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removing unnecessary commas src/java.base/share/classes/java/text/ListFormat.java line 46: > 44: * defined in Unicode Consortium's LDML specification for > 45: * > 46: * List Patterns. The main function, it seems to me, is to change the representation from one form to another. what would you think about the following: The {@code ListFormat} class is a tool for converting a list of strings to a text representation and vice versa in a locale-sensitive way. It transforms strings to text in accordance with the List Patterns (link) as defined in Unicode Consortium's LDML specification. For example, it can be used to format a list of 3 weekdays, i.e. "Monday", "Wednesday", "Friday", as "Monday, Wednesday, and Friday" in an inclusive list pattern. src/java.base/share/classes/java/text/ListFormat.java line 48: > 46: * List Patterns. > 47: *

> 48: * Three types of concatenation are provided: {@link Type#STANDARD STANDARD}, A "Type" and "Style" together make up a specific pattern. It might be good to introduce the term "List Patterns" here first, that is, moving the introduction of patterns to the class description from the 1-arg getInstance method. once we have the terms established, we can then delve into the specific cases "types" and "styles" represent. Something like:

List Patterns

List Patterns are rules that define how a series or list is formed ... (include the description for the getInstance(String[] patterns) here)

Standard Patterns

{@code ListFormat} supports a few pre-defined patterns with a combination of Type (link) and Style(link). Types and Styles are defined as follows.

Type

{@link Type#STANDARD STANDARD}: a simple list with conjunction "and"; ...

Style

{@link Style#FULL FULL}: uses the conjunction word such as "and"; {@link Style#SHORT SHORT}: uses the shorthand of the conjunction word, "&" (ampersand) for "and" for example; {@link Style#NARROW NARROW}: uses no conjunction word. For example, a combination of {@link Type#STANDARD STANDARD} and {@link Style#FULL FULL} forms an inclusive list pattern. src/java.base/share/classes/java/text/ListFormat.java line 521: > 519: var sb = new StringBuilder(256).append(patterns[START]); > 520: IntStream.range(2, count - 1).forEach(i -> sb.append(middleBetween).append("{").append(i).append("}")); > 521: sb.append(patterns[END].replaceFirst("\\{0}", "").replaceFirst("\\{1}", "\\{" + (count - 1) + "\\}")); >From what it looks, it could be a concern for potentially adding large number of long strings with a list of small items. I don't seem to see where the input is limited. src/java.base/share/classes/java/text/ListFormat.java line 560: > 558: * The {@code UNIT} ListFormat style. This style concatenates > 559: * elements, useful for enumerating units. > 560: */ The word "style" used in Type, I assume you meant "type"? Just that it might be confused with Style below. Same as previous comments, a combination of Type and Style, if I understand correctly, forms a specific pattern. I might say something about it in the enum class description. A STANDARD type then is a simple list with conjunction "and", or an inclusive list, and etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1314106218 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1314109373 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1314116397 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1314111702 From dl at openjdk.org Sun Sep 3 11:07:24 2023 From: dl at openjdk.org (Doug Lea) Date: Sun, 3 Sep 2023 11:07:24 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v22] In-Reply-To: References: Message-ID: <3-JVPrtWTaNEf5amaUglkK7JEyYlP-BepdWz8cTS_mk=.878a9ac6-1334-4fb3-87eb-d5f65ae6241c@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: Avoid jtreg test group ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14301/files - new: https://git.openjdk.org/jdk/pull/14301/files/b35efb07..9d590699 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=20-21 Stats: 31 lines in 2 files changed: 29 ins; 0 del; 2 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 redestad at openjdk.org Sun Sep 3 12:35:48 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 3 Sep 2023 12:35:48 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v4] In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 18:44:13 GMT, ??? wrote: >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.StringUpperLower.*" >> >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 27.180 ? 0.017 ns/op >> -StringUpperLower.lowerToUpper avgt 15 47.196 ? 0.066 ns/op >> -StringUpperLower.mixedToLower avgt 15 32.307 ? 0.072 ns/op >> -StringUpperLower.mixedToUpper avgt 15 44.005 ? 0.414 ns/op >> -StringUpperLower.upperToLower avgt 15 32.310 ? 0.033 ns/op >> -StringUpperLower.upperToUpper avgt 15 42.053 ? 0.341 ns/op >> >> +Benchmark Mode Cnt Score Error Units (Update 01) >> +StringUpperLower.lowerToLower avgt 15 16.964 ? 0.021 ns/op (+60.96%) >> +StringUpperLower.lowerToUpper avgt 15 46.491 ? 0.036 ns/op (+1.51%) >> +StringUpperLower.mixedToLower avgt 15 35.947 ? 0.254 ns/op (-10.12%) >> +StringUpperLower.mixedToUpper avgt 15 41.976 ? 0.326 ns/op (+4.83%) >> +StringUpperLower.upperToLower avgt 15 33.466 ? 4.036 ns/op (-3.45%) >> +StringUpperLower.upperToUpper avgt 15 17.446 ? 1.036 ns/op (+141.04%) >> >> +Benchmark Mode Cnt Score Error Units (Update 00) >> +StringUpperLower.lowerToLower avgt 15 16.976 ? 0.043 ns/op (+60.160) >> +StringUpperLower.lowerToUpper avgt 15 46.373 ? 0.086 ns/op (+1.77%) >> +StringUpperLower.mixedToLower avgt 15 32.018 ? 0.061 ns/op (+0.9%) >> +StringUpperLower.mixedToUpper avgt 15 42.019 ? 0.473 ns/op (+4.72%) >> +StringUpperLower.upperToLower avgt 15 32.052 ? 0.051 ns/op (+0.8%) >> +StringUpperLower.upperToUpper avgt 15 16.978 ? 0.190 ns/op (+147.69%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 22.164 ? 0.021 ns/op >> -StringUpperLower.lowerToUpper avgt 15 46.113 ? 0.047 ns/op >> -StringUpperLower.mixedToLower avgt 15 28.501 ? 0.037 ns/op >> -StringUpperLower.mixedToUpper avgt 15 38.782 ? 0.038 ns/op >> -StringUpperLower.upperToLower avgt 15 28.625 ? 0.162 ns/op >> -StringUpperLower.upperToUpper avgt 15 27.960 ? 0.038 ns/op >> >> +B... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > use hex literal The two odd codepoints I was curious about are `0xaa` and `0xba`, both of which are lower-case according to `Character.isLowerCase(..)` but does not actually have an uppercase. The Unicode data categorize these two as `Lo`, Letter, other, so I'm a little confused how they got tagged as lowercase. `Character.toUpperCaseEx` is specified as adhering to the definition of the unicode data (unlike some legacy java character definition that might differ subtly) so perhaps it's reasonable to specify this newly invented `isLowerCaseEx` as strictly adhering to the unicode data in which case I think `0xaa` and `0xbb` should not be considered lower case. I am not a domain expert and would like someone like @naotoj to weigh in here. But either way we should think about how to specify this kind of method to keep it precise. Even if it's only internal code.. I suggested `hasUpperCase` (or maybe `hasUpperCaseEx`) as a way out of this particular conundrum, since it makes perfect sense to define a method named like that to be equivalent to `return cp != CharacterDataLatin1.instance.toUpperCaseEx(cp);` ------------- PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1704294149 From duke at openjdk.org Sun Sep 3 17:36:03 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Sun, 3 Sep 2023 17:36:03 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v5] In-Reply-To: References: Message-ID: > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.StringUpperLower.*" > > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark Mode Cnt Score Error Units (baseline) > -StringUpperLower.lowerToLower avgt 15 27.180 ? 0.017 ns/op > -StringUpperLower.lowerToUpper avgt 15 47.196 ? 0.066 ns/op > -StringUpperLower.mixedToLower avgt 15 32.307 ? 0.072 ns/op > -StringUpperLower.mixedToUpper avgt 15 44.005 ? 0.414 ns/op > -StringUpperLower.upperToLower avgt 15 32.310 ? 0.033 ns/op > -StringUpperLower.upperToUpper avgt 15 42.053 ? 0.341 ns/op > > +Benchmark Mode Cnt Score Error Units (Update 01) > +StringUpperLower.lowerToLower avgt 15 16.964 ? 0.021 ns/op (+60.96%) > +StringUpperLower.lowerToUpper avgt 15 46.491 ? 0.036 ns/op (+1.51%) > +StringUpperLower.mixedToLower avgt 15 35.947 ? 0.254 ns/op (-10.12%) > +StringUpperLower.mixedToUpper avgt 15 41.976 ? 0.326 ns/op (+4.83%) > +StringUpperLower.upperToLower avgt 15 33.466 ? 4.036 ns/op (-3.45%) > +StringUpperLower.upperToUpper avgt 15 17.446 ? 1.036 ns/op (+141.04%) > > +Benchmark Mode Cnt Score Error Units (Update 00) > +StringUpperLower.lowerToLower avgt 15 16.976 ? 0.043 ns/op (+60.160) > +StringUpperLower.lowerToUpper avgt 15 46.373 ? 0.086 ns/op (+1.77%) > +StringUpperLower.mixedToLower avgt 15 32.018 ? 0.061 ns/op (+0.9%) > +StringUpperLower.mixedToUpper avgt 15 42.019 ? 0.473 ns/op (+4.72%) > +StringUpperLower.upperToLower avgt 15 32.052 ? 0.051 ns/op (+0.8%) > +StringUpperLower.upperToUpper avgt 15 16.978 ? 0.190 ns/op (+147.69%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark Mode Cnt Score Error Units (baseline) > -StringUpperLower.lowerToLower avgt 15 22.164 ? 0.021 ns/op > -StringUpperLower.lowerToUpper avgt 15 46.113 ? 0.047 ns/op > -StringUpperLower.mixedToLower avgt 15 28.501 ? 0.037 ns/op > -StringUpperLower.mixedToUpper avgt 15 38.782 ? 0.038 ns/op > -StringUpperLower.upperToLower avgt 15 28.625 ? 0.162 ns/op > -StringUpperLower.upperToUpper avgt 15 27.960 ? 0.038 ns/op > > +Benchmark Mode Cnt Score Error Units (Update 01) > +StringUpperLower.lowerToLo... ??? has updated the pull request incrementally with one additional commit since the last revision: rename isLowerCaseEx to hasNotUpperCaseEx ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14751/files - new: https://git.openjdk.org/jdk/pull/14751/files/a5ace579..b4761828 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14751&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14751&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14751/head:pull/14751 PR: https://git.openjdk.org/jdk/pull/14751 From duke at openjdk.org Sun Sep 3 17:37:40 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Sun, 3 Sep 2023 17:37:40 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v4] In-Reply-To: References: Message-ID: On Sun, 3 Sep 2023 12:33:18 GMT, Claes Redestad wrote: > The two odd codepoints I was curious about are `0xaa` and `0xba`, both of which are lower-case according to `Character.isLowerCase(..)` but does not actually have an uppercase. The Unicode data categorize these two as `Lo`, Letter, other, so I'm a little confused how they got tagged as lowercase. > > `Character.toUpperCaseEx` is specified as adhering to the definition of the unicode data (unlike some legacy java character definition that might differ subtly) so perhaps it's reasonable to specify this newly invented `isLowerCaseEx` as strictly adhering to the unicode data in which case I think `0xaa` and `0xbb` should not be considered lower case. I am not a domain expert and would like someone like @naotoj to weigh in here. But either way we should think about how to specify this kind of method to keep it precise. Even if it's only internal code.. > > I suggested `hasUpperCase` (or maybe `hasUpperCaseEx`) as a way out of this particular conundrum, since it makes perfect sense to define a method named like that to be equivalent to `return cp != CharacterDataLatin1.instance.toUpperCaseEx(cp);` i have renamed isLowerCaseEx to hasNotUpperCaseEx, is this ok? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1704360024 From duke at openjdk.org Sun Sep 3 17:41:40 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Sun, 3 Sep 2023 17:41:40 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v5] In-Reply-To: References: Message-ID: On Sun, 3 Sep 2023 17:36:03 GMT, ??? wrote: >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.StringUpperLower.*" >> >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 27.180 ? 0.017 ns/op >> -StringUpperLower.lowerToUpper avgt 15 47.196 ? 0.066 ns/op >> -StringUpperLower.mixedToLower avgt 15 32.307 ? 0.072 ns/op >> -StringUpperLower.mixedToUpper avgt 15 44.005 ? 0.414 ns/op >> -StringUpperLower.upperToLower avgt 15 32.310 ? 0.033 ns/op >> -StringUpperLower.upperToUpper avgt 15 42.053 ? 0.341 ns/op >> >> +Benchmark Mode Cnt Score Error Units (Update 01) >> +StringUpperLower.lowerToLower avgt 15 16.964 ? 0.021 ns/op (+60.96%) >> +StringUpperLower.lowerToUpper avgt 15 46.491 ? 0.036 ns/op (+1.51%) >> +StringUpperLower.mixedToLower avgt 15 35.947 ? 0.254 ns/op (-10.12%) >> +StringUpperLower.mixedToUpper avgt 15 41.976 ? 0.326 ns/op (+4.83%) >> +StringUpperLower.upperToLower avgt 15 33.466 ? 4.036 ns/op (-3.45%) >> +StringUpperLower.upperToUpper avgt 15 17.446 ? 1.036 ns/op (+141.04%) >> >> +Benchmark Mode Cnt Score Error Units (Update 00) >> +StringUpperLower.lowerToLower avgt 15 16.976 ? 0.043 ns/op (+60.160) >> +StringUpperLower.lowerToUpper avgt 15 46.373 ? 0.086 ns/op (+1.77%) >> +StringUpperLower.mixedToLower avgt 15 32.018 ? 0.061 ns/op (+0.9%) >> +StringUpperLower.mixedToUpper avgt 15 42.019 ? 0.473 ns/op (+4.72%) >> +StringUpperLower.upperToLower avgt 15 32.052 ? 0.051 ns/op (+0.8%) >> +StringUpperLower.upperToUpper avgt 15 16.978 ? 0.190 ns/op (+147.69%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 22.164 ? 0.021 ns/op >> -StringUpperLower.lowerToUpper avgt 15 46.113 ? 0.047 ns/op >> -StringUpperLower.mixedToLower avgt 15 28.501 ? 0.037 ns/op >> -StringUpperLower.mixedToUpper avgt 15 38.782 ? 0.038 ns/op >> -StringUpperLower.upperToLower avgt 15 28.625 ? 0.162 ns/op >> -StringUpperLower.upperToUpper avgt 15 27.960 ? 0.038 ns/op >> >> +B... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > rename isLowerCaseEx to hasNotUpperCaseEx Now the build has failed, and git rebase can solve the failure. Is there any other way? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1704360428 From redestad at openjdk.org Sun Sep 3 17:56:45 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 3 Sep 2023 17:56:45 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v5] In-Reply-To: References: Message-ID: On Sun, 3 Sep 2023 17:36:03 GMT, ??? wrote: >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.StringUpperLower.*" >> >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 27.180 ? 0.017 ns/op >> -StringUpperLower.lowerToUpper avgt 15 47.196 ? 0.066 ns/op >> -StringUpperLower.mixedToLower avgt 15 32.307 ? 0.072 ns/op >> -StringUpperLower.mixedToUpper avgt 15 44.005 ? 0.414 ns/op >> -StringUpperLower.upperToLower avgt 15 32.310 ? 0.033 ns/op >> -StringUpperLower.upperToUpper avgt 15 42.053 ? 0.341 ns/op >> >> +Benchmark Mode Cnt Score Error Units (Update 01) >> +StringUpperLower.lowerToLower avgt 15 16.964 ? 0.021 ns/op (+60.96%) >> +StringUpperLower.lowerToUpper avgt 15 46.491 ? 0.036 ns/op (+1.51%) >> +StringUpperLower.mixedToLower avgt 15 35.947 ? 0.254 ns/op (-10.12%) >> +StringUpperLower.mixedToUpper avgt 15 41.976 ? 0.326 ns/op (+4.83%) >> +StringUpperLower.upperToLower avgt 15 33.466 ? 4.036 ns/op (-3.45%) >> +StringUpperLower.upperToUpper avgt 15 17.446 ? 1.036 ns/op (+141.04%) >> >> +Benchmark Mode Cnt Score Error Units (Update 00) >> +StringUpperLower.lowerToLower avgt 15 16.976 ? 0.043 ns/op (+60.160) >> +StringUpperLower.lowerToUpper avgt 15 46.373 ? 0.086 ns/op (+1.77%) >> +StringUpperLower.mixedToLower avgt 15 32.018 ? 0.061 ns/op (+0.9%) >> +StringUpperLower.mixedToUpper avgt 15 42.019 ? 0.473 ns/op (+4.72%) >> +StringUpperLower.upperToLower avgt 15 32.052 ? 0.051 ns/op (+0.8%) >> +StringUpperLower.upperToUpper avgt 15 16.978 ? 0.190 ns/op (+147.69%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 22.164 ? 0.021 ns/op >> -StringUpperLower.lowerToUpper avgt 15 46.113 ? 0.047 ns/op >> -StringUpperLower.mixedToLower avgt 15 28.501 ? 0.037 ns/op >> -StringUpperLower.mixedToUpper avgt 15 38.782 ? 0.038 ns/op >> -StringUpperLower.upperToLower avgt 15 28.625 ? 0.162 ns/op >> -StringUpperLower.upperToUpper avgt 15 27.960 ? 0.038 ns/op >> >> +B... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > rename isLowerCaseEx to hasNotUpperCaseEx The preferred route is to merge in then push changes from master to your PR branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1704363457 From redestad at openjdk.org Sun Sep 3 18:03:39 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 3 Sep 2023 18:03:39 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v5] In-Reply-To: References: Message-ID: On Sun, 3 Sep 2023 17:36:03 GMT, ??? wrote: >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.StringUpperLower.*" >> >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 27.180 ? 0.017 ns/op >> -StringUpperLower.lowerToUpper avgt 15 47.196 ? 0.066 ns/op >> -StringUpperLower.mixedToLower avgt 15 32.307 ? 0.072 ns/op >> -StringUpperLower.mixedToUpper avgt 15 44.005 ? 0.414 ns/op >> -StringUpperLower.upperToLower avgt 15 32.310 ? 0.033 ns/op >> -StringUpperLower.upperToUpper avgt 15 42.053 ? 0.341 ns/op >> >> +Benchmark Mode Cnt Score Error Units (Update 01) >> +StringUpperLower.lowerToLower avgt 15 16.964 ? 0.021 ns/op (+60.96%) >> +StringUpperLower.lowerToUpper avgt 15 46.491 ? 0.036 ns/op (+1.51%) >> +StringUpperLower.mixedToLower avgt 15 35.947 ? 0.254 ns/op (-10.12%) >> +StringUpperLower.mixedToUpper avgt 15 41.976 ? 0.326 ns/op (+4.83%) >> +StringUpperLower.upperToLower avgt 15 33.466 ? 4.036 ns/op (-3.45%) >> +StringUpperLower.upperToUpper avgt 15 17.446 ? 1.036 ns/op (+141.04%) >> >> +Benchmark Mode Cnt Score Error Units (Update 00) >> +StringUpperLower.lowerToLower avgt 15 16.976 ? 0.043 ns/op (+60.160) >> +StringUpperLower.lowerToUpper avgt 15 46.373 ? 0.086 ns/op (+1.77%) >> +StringUpperLower.mixedToLower avgt 15 32.018 ? 0.061 ns/op (+0.9%) >> +StringUpperLower.mixedToUpper avgt 15 42.019 ? 0.473 ns/op (+4.72%) >> +StringUpperLower.upperToLower avgt 15 32.052 ? 0.051 ns/op (+0.8%) >> +StringUpperLower.upperToUpper avgt 15 16.978 ? 0.190 ns/op (+147.69%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringUpperLower.lowerToLower avgt 15 22.164 ? 0.021 ns/op >> -StringUpperLower.lowerToUpper avgt 15 46.113 ? 0.047 ns/op >> -StringUpperLower.mixedToLower avgt 15 28.501 ? 0.037 ns/op >> -StringUpperLower.mixedToUpper avgt 15 38.782 ? 0.038 ns/op >> -StringUpperLower.upperToLower avgt 15 28.625 ? 0.162 ns/op >> -StringUpperLower.upperToUpper avgt 15 27.960 ? 0.038 ns/op >> >> +B... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > rename isLowerCaseEx to hasNotUpperCaseEx `hasNotUpperCaseEx` sounds wrong. `hasUpperCaseMapping`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1704364653 From duke at openjdk.org Sun Sep 3 23:55:57 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Sun, 3 Sep 2023 23:55:57 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v6] In-Reply-To: References: Message-ID: <4Hvl1gwzUCV3I5dRgsAuU5qrFKs6tB0aUUEn6_s3cGA=.03db1c71-8954-4a34-9c2a-06654073db12@github.com> > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.StringUpperLower.*" > > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark Mode Cnt Score Error Units (baseline) > -StringUpperLower.lowerToLower avgt 15 27.180 ? 0.017 ns/op > -StringUpperLower.lowerToUpper avgt 15 47.196 ? 0.066 ns/op > -StringUpperLower.mixedToLower avgt 15 32.307 ? 0.072 ns/op > -StringUpperLower.mixedToUpper avgt 15 44.005 ? 0.414 ns/op > -StringUpperLower.upperToLower avgt 15 32.310 ? 0.033 ns/op > -StringUpperLower.upperToUpper avgt 15 42.053 ? 0.341 ns/op > > +Benchmark Mode Cnt Score Error Units (Update 01) > +StringUpperLower.lowerToLower avgt 15 16.964 ? 0.021 ns/op (+60.96%) > +StringUpperLower.lowerToUpper avgt 15 46.491 ? 0.036 ns/op (+1.51%) > +StringUpperLower.mixedToLower avgt 15 35.947 ? 0.254 ns/op (-10.12%) > +StringUpperLower.mixedToUpper avgt 15 41.976 ? 0.326 ns/op (+4.83%) > +StringUpperLower.upperToLower avgt 15 33.466 ? 4.036 ns/op (-3.45%) > +StringUpperLower.upperToUpper avgt 15 17.446 ? 1.036 ns/op (+141.04%) > > +Benchmark Mode Cnt Score Error Units (Update 00) > +StringUpperLower.lowerToLower avgt 15 16.976 ? 0.043 ns/op (+60.160) > +StringUpperLower.lowerToUpper avgt 15 46.373 ? 0.086 ns/op (+1.77%) > +StringUpperLower.mixedToLower avgt 15 32.018 ? 0.061 ns/op (+0.9%) > +StringUpperLower.mixedToUpper avgt 15 42.019 ? 0.473 ns/op (+4.72%) > +StringUpperLower.upperToLower avgt 15 32.052 ? 0.051 ns/op (+0.8%) > +StringUpperLower.upperToUpper avgt 15 16.978 ? 0.190 ns/op (+147.69%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark Mode Cnt Score Error Units (baseline) > -StringUpperLower.lowerToLower avgt 15 22.164 ? 0.021 ns/op > -StringUpperLower.lowerToUpper avgt 15 46.113 ? 0.047 ns/op > -StringUpperLower.mixedToLower avgt 15 28.501 ? 0.037 ns/op > -StringUpperLower.mixedToUpper avgt 15 38.782 ? 0.038 ns/op > -StringUpperLower.upperToLower avgt 15 28.625 ? 0.162 ns/op > -StringUpperLower.upperToUpper avgt 15 27.960 ? 0.038 ns/op > > +Benchmark Mode Cnt Score Error Units (Update 01) > +StringUpperLower.lowerToLo... ??? has updated the pull request incrementally with one additional commit since the last revision: rename hasNotUpperCaseEx to hasUpperCaseMapping ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14751/files - new: https://git.openjdk.org/jdk/pull/14751/files/b4761828..26aa8b19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14751&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14751&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14751/head:pull/14751 PR: https://git.openjdk.org/jdk/pull/14751 From duke at openjdk.org Mon Sep 4 01:20:46 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 4 Sep 2023 01:20:46 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v5] In-Reply-To: References: Message-ID: <5NEhen5o_IVqxBzprMqLzmgXY8omXJmQwVuHjZket6g=.8ad4a0e5-996c-460c-9087-d7b728935f37@github.com> On Sun, 3 Sep 2023 17:54:02 GMT, Claes Redestad wrote: > The preferred route is to merge in then push changes from master to your PR branch. Merge will cause a lot of file changes > `hasNotUpperCaseEx` sounds wrong. `hasUpperCaseMapping`? i have renamed hasNotUpperCaseEx to hasUpperCaseMapping. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1704475117 PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1704475354 From duke at openjdk.org Mon Sep 4 03:26:48 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 4 Sep 2023 03:26:48 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v13] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: <2HfU2bCNLnOy5kUoexFxUel13Pb3uBfY9SOEG7Orqis=.5cf9c774-65d6-4121-898f-2e0c4e23d0e3@github.com> On Fri, 1 Sep 2023 12:01:58 GMT, ??? wrote: >> @cl4es can you help me to review this PR? > >> @wenshao How about of approach used in [James Anhalt's algorithm](https://jk-jeon.github.io/posts/2022/02/jeaiii-algorithm/)? >> >> It reduces number of multiplications ([and store operations in case of writing by 4-8 byte words](https://github.com/plokhotnyuk/jsoniter-scala/blob/b1020bafa7e2e5b7e8dd87b86a9e860975f4695e/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonWriter.scala#L2004-L2023)) but increases the total number of instructions for the routine. > > If the compiled code size is greater than 325 (FreqInlineSize), it will not be inlined and performance will slow down. This algorithm obviously greater than 325. > > different algorithms perform differently on different types of tiny/small/big values. > > The [first commit](https://github.com/openjdk/jdk/pull/14699/files/8bdda26b8bb7f6162592a07445ecd2285e4fabaa) of this PR performs better under big values. But I still use the current algorithm, with few changes, and performance can be improved in all scenarios. > @wenshao Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information. to solve the problem of build failure, i did git rebase & push force. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1704556037 From qamai at openjdk.org Mon Sep 4 04:09:38 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 4 Sep 2023 04:09:38 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v12] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> <6Z9eOwWQA7NeLDOsYW0Oh373ArzaZIGk0JaWFGWfOj4=.40bb7830-6405-4d3e-9a4e-e17b3b066871@github.com> Message-ID: <-xUT6tyB-PGCr5i3fC6pE5D9QdFl_YkjiaEU8shWC2Y=.18e744b2-d6dd-4b1e-932b-74c668a04997@github.com> On Thu, 20 Jul 2023 09:20:00 GMT, ??? wrote: >> src/java.base/share/classes/java/lang/Long.java line 527: >> >>> 525: /** >>> 526: * Places characters representing the long i into the >>> 527: * character array buf. The characters are placed into >> >> Add the array bound check for the store of the characters. > > I added assert with reference to the implementation of StringUTF16#putChar, is this safe enough? Can you use `VarHandle` here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1314416729 From duke at openjdk.org Mon Sep 4 05:05:04 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 4 Sep 2023 05:05:04 GMT Subject: RFR: 8315585: Optimization for decimal to string Message-ID: BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. The performance data is as follows: ## 1. benchmark script sh make/devkit/createJMHBundle.sh bash configure --with-jmh=build/jmh/jars make test TEST="micro:java.math.BigDecimals.*ToPlainString" make test TEST="micro:java.math.BigDecimals.*ToEngineering" ## 2. benchmark environment * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) * cpu intel xeon sapphire rapids (x64) ## 3. benchmark result -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op +Benchmark Mode Cnt Score Error Units (optimize) +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) -Benchmark Mode Cnt Score Error Units (baseline) -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op +Benchmark Mode Cnt Score Error Units (optimize) +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) +BigDecimals.testSmallToEngineeringString avgt 15 10.579 ? 0.066 ns/op (+43.13%) +BigDecimals.testToEngineeringString avgt 15 1646.783 ? 3.060 ns/op (+10.15%) ------------- Commit messages: - update copyright info - optimization for decimal to string Changes: https://git.openjdk.org/jdk/pull/15555/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315585 Stats: 748 lines in 4 files changed: 522 ins; 33 del; 193 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From duke at openjdk.org Mon Sep 4 05:09:39 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 4 Sep 2023 05:09:39 GMT Subject: RFR: 8315585: Optimization for decimal to string In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 04:58:08 GMT, ??? wrote: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... @cl4es can you help me to review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1704617230 From duke at openjdk.org Mon Sep 4 06:50:18 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 4 Sep 2023 06:50:18 GMT Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v7] In-Reply-To: References: Message-ID: > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.StringUpperLower.*" > > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark Mode Cnt Score Error Units (baseline) > -StringUpperLower.lowerToLower avgt 15 27.180 ? 0.017 ns/op > -StringUpperLower.lowerToUpper avgt 15 47.196 ? 0.066 ns/op > -StringUpperLower.mixedToLower avgt 15 32.307 ? 0.072 ns/op > -StringUpperLower.mixedToUpper avgt 15 44.005 ? 0.414 ns/op > -StringUpperLower.upperToLower avgt 15 32.310 ? 0.033 ns/op > -StringUpperLower.upperToUpper avgt 15 42.053 ? 0.341 ns/op > > +Benchmark Mode Cnt Score Error Units (Update 01) > +StringUpperLower.lowerToLower avgt 15 16.964 ? 0.021 ns/op (+60.96%) > +StringUpperLower.lowerToUpper avgt 15 46.491 ? 0.036 ns/op (+1.51%) > +StringUpperLower.mixedToLower avgt 15 35.947 ? 0.254 ns/op (-10.12%) > +StringUpperLower.mixedToUpper avgt 15 41.976 ? 0.326 ns/op (+4.83%) > +StringUpperLower.upperToLower avgt 15 33.466 ? 4.036 ns/op (-3.45%) > +StringUpperLower.upperToUpper avgt 15 17.446 ? 1.036 ns/op (+141.04%) > > +Benchmark Mode Cnt Score Error Units (Update 00) > +StringUpperLower.lowerToLower avgt 15 16.976 ? 0.043 ns/op (+60.160) > +StringUpperLower.lowerToUpper avgt 15 46.373 ? 0.086 ns/op (+1.77%) > +StringUpperLower.mixedToLower avgt 15 32.018 ? 0.061 ns/op (+0.9%) > +StringUpperLower.mixedToUpper avgt 15 42.019 ? 0.473 ns/op (+4.72%) > +StringUpperLower.upperToLower avgt 15 32.052 ? 0.051 ns/op (+0.8%) > +StringUpperLower.upperToUpper avgt 15 16.978 ? 0.190 ns/op (+147.69%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark Mode Cnt Score Error Units (baseline) > -StringUpperLower.lowerToLower avgt 15 22.164 ? 0.021 ns/op > -StringUpperLower.lowerToUpper avgt 15 46.113 ? 0.047 ns/op > -StringUpperLower.mixedToLower avgt 15 28.501 ? 0.037 ns/op > -StringUpperLower.mixedToUpper avgt 15 38.782 ? 0.038 ns/op > -StringUpperLower.upperToLower avgt 15 28.625 ? 0.162 ns/op > -StringUpperLower.upperToUpper avgt 15 27.960 ? 0.038 ns/op > > +Benchmark Mode Cnt Score Error Units (Update 01) > +StringUpperLower.lowerToLo... ??? has updated the pull request with a new target base 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' of github.com:wenshao/jdk into optimization_for_string_latin1_upper_lower - rename hasNotUpperCaseEx to hasUpperCaseMapping - rename isLowerCaseEx to hasNotUpperCaseEx - use hex literal - add method CharacterDataLatin1#isLowerCaseEx - remove unnecessary code - optimization for StringLatin1 UpperLower ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14751/files - new: https://git.openjdk.org/jdk/pull/14751/files/26aa8b19..a38f8870 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14751&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14751&range=05-06 Stats: 148954 lines in 2871 files changed: 61152 ins; 70989 del; 16813 mod Patch: https://git.openjdk.org/jdk/pull/14751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14751/head:pull/14751 PR: https://git.openjdk.org/jdk/pull/14751 From pminborg at openjdk.org Mon Sep 4 06:54:40 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 4 Sep 2023 06:54:40 GMT Subject: RFR: 8315454: Add a way to create an immutable snapshot of a BitSet [v4] In-Reply-To: References: Message-ID: > This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: > > PoolReader (6) > URLEncoder (1) - Updated in this PR > HtmlTree (2) > > More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. > > Initial benchmarks with the URLEncoder show encouraging results: > > > Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% > URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Do not propagate Integer.MAX_VALUE BitSets ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15530/files - new: https://git.openjdk.org/jdk/pull/15530/files/c3977aa3..6f80e0b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15530&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15530&range=02-03 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15530.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15530/head:pull/15530 PR: https://git.openjdk.org/jdk/pull/15530 From jpai at openjdk.org Mon Sep 4 07:17:37 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 4 Sep 2023 07:17:37 GMT Subject: RFR: 8233160: Add java.vendor.url.bug to list of recognized standard system properties In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 06:53:45 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8233160? > > It has been noted in https://bugs.openjdk.org/browse/JDK-8232753 that: > >> The java.vendor.url.bug property has been defined by every Sun/Oracle JDK going all the way back to JDK 5 (and possibly earlier; JDK 5 is the oldest release that I can still run on my development machine). Yet, it's never been specified. > > The OpenJDK builds too by default set a value for this system property. > > The commit in this PR updates the javadoc of `System.getProperties()` to include this system property in the list of specified properties. Additionally, the `test/jdk/java/lang/System/PropertyTest.java` test has been updated to verify that this property is indeed available in the Properties returned by `System.getProperites()`. > > I'll create a CSR shortly for this change. I've now created a CSR for this issue https://bugs.openjdk.org/browse/JDK-8315601 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15504#issuecomment-1704735619 From jvernee at openjdk.org Mon Sep 4 07:31:43 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 07:31:43 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Fri, 25 Aug 2023 10:59:45 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary imports. Sorry for the delay, I've been on vacation. src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 398: > 396: bindings.add(Binding.cast(type, int.class)); > 397: type = int.class; > 398: } Part of the casts are handled here with explicit cast bindings, but the widening from int -> long, and narrowing from long -> int are handled implicitly as part of the ShiftLeft implementation. I'd much prefer if all the type conversions are handled with explicit cast bindings. This would also semantically simplify the shift operator, since it would just handle the actual shifting. src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 695: > 693: * Negative [shiftAmount] shifts right and converts to int if needed. > 694: */ > 695: record ShiftLeft(int shiftAmount, Class type) implements Binding { Please split this into 2 binding operators: one for ShiftLeft and another for (arithmetic) ShiftRight, rather than mixing the 2 implementations into a single operator. For the right shift you could then also use a positive shift amount, and avoid the double negation that's needed right now. src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 703: > 701: if (last != ((type == long.class) ? long.class : int.class)) > 702: throw new IllegalArgumentException( > 703: String.format("Invalid operand type: %s. integral type expected", last)); Why not use `SharedUtils.checkType` here? Suggestion: SharedUtils.checkType(last, type); src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 711: > 709: stack.push(type == long.class ? long.class : int.class); > 710: } else > 711: throw new IllegalArgumentException("shiftAmount 0 not supported"); Please handle this validation in the static `shiftLeft` method. That's also where we do validation for other binding ops src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 737: > 735: cb.i2l(); > 736: typeStack.pop(); > 737: typeStack.push(long.class); Please use `popType` and `pushType` instead of manipulating the type stack manually. The former also does some verification. This should happen along every control path. Even if the binding is 1-to-1 (like this one) and doesn't change the type of the value, this would validate that the input type is correct, and make sure that any bugs are caught early. ------------- PR Review: https://git.openjdk.org/jdk/pull/15417#pullrequestreview-1595698959 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305681864 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314518216 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305642804 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305668315 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305650457 From jvernee at openjdk.org Mon Sep 4 07:31:44 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 07:31:44 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <-H8TLXCvHxTIMGSl0vfnuPByyVX1olhlQzNtKut6aa8=.1094aa6b-60c9-430c-99f2-9af72f994191@github.com> <9eDbDxSzdUMYrRDZh8XMiSd2Np4JrwAy2l6jSyykEVA=.1d009a67-a8e9-4868-8244-d244b8653729@github.com> Message-ID: On Fri, 25 Aug 2023 09:24:15 GMT, Maurizio Cimadamore wrote: >> The ABI says: "An aggregate or union smaller than one doubleword in size is padded so that it appears in the least significant bits of the doubleword. All others are padded, if necessary, at their tail." [https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#PARAM-PASS]. >> I have written examples which pass 9 and 15 Bytes. >> In the first case, we need to get 0x0001020304050607 in the first argument and 0x08XXXXXXXXXXXXXX into the second argument (X is "don't care"). Shift amount is 7. >> In the second case, we need to get 0x0001020304050607 in the first argument and 0x08090a0b0c0d0eXX into the second argument. Shift amount is 1. >> In other words, we need shift amounts between 1 and 7. Stack slots and registers are always 64 bit on PPC64. > > Got it - I found these representations: > > https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.7.html#BYTEORDER > > Very helpful. So you have e.g. a `short` value (loaded from somewhere) and you have to store it on a double-word. Now, if you just stored it at offset 0, you will write the bits 0-15, which are the "most" significant bits in big-endian representation. So, it's backwards. I believe FFM will take care of endianness, so that the bytes 0-7 and 8-15 will be "swapped" when writing into the double-word (right?) but their base offset (0) is still off, as they should really start at offset 48. Hence the shift. After looking for a while, I think having the new binding operator is needed. e.g. for stores: we load a 32 bit value from the end of a struct, then the low-order bits of the value needs to be padded with zeros to get a 64 bit register value, leaving the original 32 bit value in the high order bits. This can't be handled by the current cast operator. e.g. if we had an int -> long cast conversion, then in the resulting value the low-order bits would be occupied by the 32 bit value, which is incorrect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314524955 From shade at openjdk.org Mon Sep 4 07:34:09 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 4 Sep 2023 07:34:09 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 Message-ID: Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/15556/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15556&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315578 Stats: 12 lines in 3 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15556/head:pull/15556 PR: https://git.openjdk.org/jdk/pull/15556 From shade at openjdk.org Mon Sep 4 07:36:03 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 4 Sep 2023 07:36:03 GMT Subject: RFR: 8315579: SPARC64 builds are broken after JDK-8304913 Message-ID: Similar to other issues in the same area. I have no SPARC machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the SPARC Zero build completes fine. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/15557/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15557&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315579 Stats: 13 lines in 3 files changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15557.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15557/head:pull/15557 PR: https://git.openjdk.org/jdk/pull/15557 From jwaters at openjdk.org Mon Sep 4 08:03:42 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 4 Sep 2023 08:03:42 GMT Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v7] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 20:34:01 GMT, Vladimir Petko wrote: >> 8314491: Linux: jexec launched via PATH fails to find java > > Vladimir Petko has updated the pull request with a new target base 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 8314491-jexec-resolve-symlink > - Merge branch 'master' into 8314491-jexec-resolve-symlink > - declare error in-place > - remove unused imports > - Review comment: use /proc/self/exe as the backup option > - Merge branch 'master' into 8314491-jexec-resolve-symlink > - correct copyright statement > - Use /proc/self/exec to identify path to the executable. > - Create failing test for jexec in PATH issue Is this all clear for sponsorship? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15343#issuecomment-1704796665 From jvernee at openjdk.org Mon Sep 4 08:16:21 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 08:16:21 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v6] 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 22 commits: - Merge branch 'master' into JEP22 - Merge branch 'master' into JEP22 - remove spurious imports - enable fallback linker on linux x86 in GHA - make Arena::allocate abstract - 8313894: Rename isTrivial linker option to critical Reviewed-by: pminborg, mcimadamore - 8313680: Disallow combining caputreCallState with isTrivial Reviewed-by: mcimadamore - Merge branch 'master' into JEP22 - use immutable map for fallback linker canonical layouts - 8313265: Move the FFM API out of preview Reviewed-by: mcimadamore - ... and 12 more: https://git.openjdk.org/jdk/compare/adfc1d6c...fd0512f8 ------------- Changes: https://git.openjdk.org/jdk/pull/15103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=05 Stats: 2839 lines in 233 files changed: 1257 ins; 894 del; 688 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 clanger at openjdk.org Mon Sep 4 08:20:44 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 4 Sep 2023 08:20:44 GMT Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows when run as user with Administrator privileges [v2] In-Reply-To: <6XbXvXBp_UUhj1UNGnSRwCzURb_DhWjX8CPOXJY5OjA=.383899d1-57be-400f-94bc-70b500d8ebfd@github.com> References: <6XbXvXBp_UUhj1UNGnSRwCzURb_DhWjX8CPOXJY5OjA=.383899d1-57be-400f-94bc-70b500d8ebfd@github.com> Message-ID: On Fri, 1 Sep 2023 08:32:20 GMT, Christoph Langer wrote: >> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible. > > Christoph Langer has updated the pull request with a new target base 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: > > - Use System.getProperty(user.name) for the Windows Adminstrators case > - Merge branch 'master' into JDK-8314094 > - JDK-8314094 OK, the latest update seems to work. I'll integrate tomorrow, unless I hear concerns. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15222#issuecomment-1704820273 From alanb at openjdk.org Mon Sep 4 08:24:19 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Sep 2023 08:24:19 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v2] In-Reply-To: References: Message-ID: > In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM. > > The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition. > > Testing: tier1-5 Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Check for transition during stack walk for synchronous case - Merge - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15492/files - new: https://git.openjdk.org/jdk/pull/15492/files/04a920d6..18f63cbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15492&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15492&range=00-01 Stats: 3227 lines in 105 files changed: 2522 ins; 385 del; 320 mod Patch: https://git.openjdk.org/jdk/pull/15492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15492/head:pull/15492 PR: https://git.openjdk.org/jdk/pull/15492 From jvernee at openjdk.org Mon Sep 4 08:25:25 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 08:25:25 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v7] In-Reply-To: References: Message-ID: <-iK5sthUj7XUrkiRP38qwQ3mknsNaR70ipgnvOhdykY=.0093ab55-a85a-492f-95c7-2fab747eb551@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: add test for unmodifiable canonical layouts map ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/fd0512f8..efc5ef4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=05-06 Stats: 6 lines in 1 file changed: 5 ins; 0 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 vpetko at openjdk.org Mon Sep 4 08:25:43 2023 From: vpetko at openjdk.org (Vladimir Petko) Date: Mon, 4 Sep 2023 08:25:43 GMT Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v7] In-Reply-To: References: Message-ID: <0mjBXK7hAysNHC107XNrI-JTxHawhisWNU-qiWx0UUY=.b92b3550-b229-4449-bdc2-e9e0b4c82b31@github.com> On Mon, 4 Sep 2023 08:01:16 GMT, Julian Waters wrote: > Is this all clear for sponsorship? Yes, I have checked with @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/15343#issuecomment-1704827486 From azeller at openjdk.org Mon Sep 4 08:25:45 2023 From: azeller at openjdk.org (Arno Zeller) Date: Mon, 4 Sep 2023 08:25:45 GMT Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows when run as user with Administrator privileges [v2] In-Reply-To: <6XbXvXBp_UUhj1UNGnSRwCzURb_DhWjX8CPOXJY5OjA=.383899d1-57be-400f-94bc-70b500d8ebfd@github.com> References: <6XbXvXBp_UUhj1UNGnSRwCzURb_DhWjX8CPOXJY5OjA=.383899d1-57be-400f-94bc-70b500d8ebfd@github.com> Message-ID: On Fri, 1 Sep 2023 08:32:20 GMT, Christoph Langer wrote: >> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible. > > Christoph Langer has updated the pull request with a new target base 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: > > - Use System.getProperty(user.name) for the Windows Adminstrators case > - Merge branch 'master' into JDK-8314094 > - JDK-8314094 Looks good to me. ------------- Marked as reviewed by azeller (Author). PR Review: https://git.openjdk.org/jdk/pull/15222#pullrequestreview-1609013076 From alanb at openjdk.org Mon Sep 4 09:02:39 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Sep 2023 09:02:39 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v2] In-Reply-To: <4v3bHT95mK5u1ij2cXIK-UUnL_-Y0D-hTaSMRtfEr2g=.57272997-e290-4c2d-9d10-8a30bd742825@github.com> References: <4v3bHT95mK5u1ij2cXIK-UUnL_-Y0D-hTaSMRtfEr2g=.57272997-e290-4c2d-9d10-8a30bd742825@github.com> Message-ID: On Fri, 1 Sep 2023 11:32:45 GMT, Markus Gr?nlund wrote: >> Thanks. One other thing that I see when more testing with generational ZGC is that ZPageAllocator::alloc_page will record an event and this can happen during a mount transition. So I think JfrStackTrace::record also needs to test if the current thread is a virtual thread without a continuation mounted. > > That is not good. Such a check would be attributed to all event sites, making them all slower. Markus has suggested, and provided the change, to handle the synchronous case in JfrStackTrace. The testing is looking good with the combined changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1314643730 From alanb at openjdk.org Mon Sep 4 09:11:38 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Sep 2023 09:11:38 GMT Subject: RFR: 8233160: Add java.vendor.url.bug to list of recognized standard system properties In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 14:59:19 GMT, Jaikiran Pai wrote: > I asked for Mark's and Joe's inputs on this in the linked JBS issue https://bugs.openjdk.org/browse/JDK-8233160. Mark has suggested that we keep this `java.vendor.url.bug` system property non-optional and also not to add any expectations of the value for this property to be a parsable URL. Okay but just to mention that in recent years, the system properties table have added "may be interpreted as a XXXX" to the description of the value of several properties so that it can be used at run-time. A bug reporting URL is probably only interesting to print out or log but maybe it's not too off-piste to think about a popup window or something might want to call URI.create and represent it as a URI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15504#issuecomment-1704896205 From duke at openjdk.org Mon Sep 4 09:20:43 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 4 Sep 2023 09:20:43 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v7] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: <-vAXjDBXVUkdL0B5bV482cczdC56yyytLE-4UOsq8SM=.eb3db869-8f84-46c5-8dab-b15796b591db@github.com> On Sat, 8 Jul 2023 00:20:20 GMT, ??? wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) >> >> >> >> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > fix typo @RogerRiggs What changes do I need to make to start the integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1704910527 From duke at openjdk.org Mon Sep 4 09:23:41 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 4 Sep 2023 09:23:41 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v17] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Fri, 1 Sep 2023 18:40:55 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - remove unused import > - UTF16 & Latin1 use same lookup table > - assert bounds check > - Integer/Long toString test against compact strings > > Co-authored-by: liach > - Adapt endian in pack > > Co-authored-by: liach > - use upper case for static final field > - private static final Unsafe > - code format > - simplify code > - format code & comment > - ... and 6 more: https://git.openjdk.org/jdk/compare/2f7c65ec...0d149fa9 @RogerRiggs Is it okay to use asserts to check boundaries? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1704914969 From asotona at openjdk.org Mon Sep 4 09:30:39 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 4 Sep 2023 09:30:39 GMT Subject: RFR: 8315444: Convert test/jdk/tools to Classfile API In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 08:14:26 GMT, Qing Xiao wrote: > /test/jdk/tools/lib/tests/JImageValidator.java, tests in /test/jdk/tools/jlink and /test/jdk/tools/jimage use on com.sun.tools.classfile and should be converted to Classfile API. Following tier2 test is affected by the change and fails: test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/15529#issuecomment-1704925079 From dl at openjdk.org Mon Sep 4 10:08:45 2023 From: dl at openjdk.org (Doug Lea) Date: Mon, 4 Sep 2023 10:08:45 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v23] 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 67 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8288899 - Avoid jtreg test group - Ignore more stray interrupts by test harness - Merge branch 'openjdk:master' into JDK-8288899 - Fix tests, undo workarounds - Avoid unwanted jtreg interrupts; undo unnecessary changes - Merge branch 'openjdk:master' into JDK-8288899 - Clear interrupts at top level - Conditionalize new tests - Isolate unexpected interrupt status issues - ... and 57 more: https://git.openjdk.org/jdk/compare/892dc0cf...551a9cf8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14301/files - new: https://git.openjdk.org/jdk/pull/14301/files/9d590699..551a9cf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=21-22 Stats: 1434 lines in 37 files changed: 1186 ins; 157 del; 91 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 Mon Sep 4 10:23:08 2023 From: duke at openjdk.org (duke) Date: Mon, 4 Sep 2023 10:23:08 GMT Subject: Withdrawn: 8180892: Correct handling of annotations on parameters In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 04:34:34 GMT, Chen Liang wrote: > This patch aims to correct handling of annotations on parameters with the help of `MethodParameters` attribute, which will be always available once #9862 is integrated. > > It utilizes and expands upon the existing parameter matching logic present in `Executable::getAllGenericParameterTypes`, and delegate parameter parameterized types, parameter annotation, and parameter type annotation accesses through the matched results, if matching is available. If matching failed, it falls back to existing heuristics that works without `MethodParameters` attributes for annotations, in `Executable::handleParameterNumberMismatch` and `TypeAnnotationParser::buildAnnotatedTypes` (renamed `buildAnnotatedTypesWithHeuristics` in this patch) > > `ParameterMappingTest` covers these scenarios with class files that have `MethodParameters` or `Signature` attributes stripped or preserved to ensure the new Reflection API implementation works for both class files generated before #9862 and after its integration. > > Also special thanks to Joe Darcy for reviewing 8304918 (#13183); this brings much convenience to this patch. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13664 From jvernee at openjdk.org Mon Sep 4 10:56:09 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 10:56:09 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v8] 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: fix TestIllegalLink on x86 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/efc5ef4a..470fcb9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=06-07 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 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 mbaesken at openjdk.org Mon Sep 4 11:01:06 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Sep 2023 11:01:06 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v4] In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: <86maccfrzpjxVqqle-l3ZVAU9kadnS-_jSx-Dc9PZt8=.3ef956b6-8eee-4664-aab2-e676b37821bb@github.com> > We run into some BackingStoreException: Couldn't get file lock. e.g. here : > > [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) > [JShell] ... 4 more > > The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Use PrivilegedAction to get OS name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15308/files - new: https://git.openjdk.org/jdk/pull/15308/files/d385dac1..b63064ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15308&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15308&range=02-03 Stats: 6 lines in 1 file changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15308.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15308/head:pull/15308 PR: https://git.openjdk.org/jdk/pull/15308 From lkorinth at openjdk.org Mon Sep 4 11:04:44 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 4 Sep 2023 11:04:44 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com> On Wed, 30 Aug 2023 09:23:55 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 one additional commit since the last revision: > > fix static import 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1705068700 From jvernee at openjdk.org Mon Sep 4 11:33:30 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 11:33:30 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v9] 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: remove unsupported linker test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/470fcb9d..ea3daaed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=07-08 Stats: 40 lines in 1 file changed: 0 ins; 40 del; 0 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 redestad at openjdk.org Mon Sep 4 11:37:41 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 4 Sep 2023 11:37:41 GMT Subject: RFR: 8315454: Add a way to create an immutable snapshot of a BitSet [v4] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 06:54:40 GMT, Per Minborg wrote: >> This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. >> >> The predicate is eligible for constant folding. >> >> Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: >> >> PoolReader (6) >> URLEncoder (1) - Updated in this PR >> HtmlTree (2) >> >> More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. >> >> Initial benchmarks with the URLEncoder show encouraging results: >> >> >> Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% >> URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) >> URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) >> URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Do not propagate Integer.MAX_VALUE BitSets Looks good to me. Since we're not adding any public API I think it's ok to include the `URLEncoder` changes so that we can use that benchmark as a proxy for verifying `BitSet::asPredicate` performance. src/java.base/share/classes/jdk/internal/util/ImmutableBitSetPredicate.java line 60: > 58: public static IntPredicate of(BitSet original) { > 59: // Do not propagate the Integer.MAX_VALUE issue > 60: if (Integer.toUnsignedLong(original.length()) > Integer.MAX_VALUE) { I'm not so sure about this. While there are issues related to `BitSet::set(Integer.MAX_VALUE)` (makes `BitSet::length` overflow to negative), the `get/test` operation is not adversely affected. Since this is an internal API adding limitations here seem a bit gratuitous and could instead be discussed if/when taking this public. test/jdk/java/util/BitSet/ImmutableBitSet.java line 2: > 1: /* > 2: * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15530#pullrequestreview-1609364523 PR Review Comment: https://git.openjdk.org/jdk/pull/15530#discussion_r1314830577 PR Review Comment: https://git.openjdk.org/jdk/pull/15530#discussion_r1314830746 From mbaesken at openjdk.org Mon Sep 4 12:00:42 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Sep 2023 12:00:42 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: On Fri, 1 Sep 2023 13:27:58 GMT, Alan Bateman wrote: > > Hi Alan , Your assumption 'I assume the use of System.getProperty is problematic when running with a SM.' is most likely correct. > > You'll need to test with a SM that denies reading the system property to be sure. There are classes in many tool APIs (you've listed some) where this doesn't arise. > For java.management/share/classes/sun/management/VMManagementImpl.java I tried with a security manager and had to grant property access so that it worked properly. For java.desktop/share/classes/sun/awt/FontConfiguration.java this can be called from all code working with fonts so it needs to be handled too (e.g. PrivilegedAction). Should I file a JBS issue for those two ? Some of the others listed might indeed fall into the tool APIs you mentioned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1705142502 From aturbanov at openjdk.org Mon Sep 4 12:16:52 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Sep 2023 12:16:52 GMT Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v4] In-Reply-To: References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com> Message-ID: On Wed, 29 Mar 2023 18:05:46 GMT, Brian Burkhalter wrote: >> Modify the `Space` instances used for size comparison to be created with total number of bytes derived from the Windows `diskFree` utility instead of Cygwin?s `df`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8305157: Clean up It seems after refactoring test started to fail on my Win11 VM. STDOUT: --- Testing volumes Total bytes : 299,877,003,264 (279.3 GB) Total quota free bytes : 202,708,971,520 (188.8 GB) Unavailable pool bytes : 0 ( 0.0 KB) Quota unavailable pool bytes : 0 ( 0.0 KB) Used bytes : 92,833,345,536 ( 86.5 GB) Total Reserved bytes : 4,334,686,208 ( 4.0 GB) Volume storage reserved bytes : 4,296,867,840 ( 4.0 GB) Available committed bytes : 0 ( 0.0 KB) Pool available bytes : 0 ( 0.0 KB) SecurityManager = null C:\ (299877003264): getSpace0 total = 299877003264 free = 202708967424 usable = 202708967424 getXSpace total = 299877003264 free = 202708967424 usable = 202708967424 STDERR: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by GetXSpace (file:/C:/Projects/jdk/build/windows-x86_64-server-slowdebug/test-support/jtreg_test_jdk_java_io_File/classes/2/java/io/File/GetXSpace.d/) WARNING: Please consider reporting this to the maintainers of GetXSpace WARNING: System::setSecurityManager will be removed in a future release java.lang.RuntimeException: The parameter is incorrect at GetXSpace.getSpace0(Native Method) at GetXSpace$Space.(GetXSpace.java:112) at GetXSpace.testVolumes(GetXSpace.java:431) at GetXSpace.main(GetXSpace.java:469) 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) JavaTest Message: Test threw exception: java.lang.RuntimeException: The parameter is incorrect ------------- PR Comment: https://git.openjdk.org/jdk/pull/12397#issuecomment-1705164515 From mdoerr at openjdk.org Mon Sep 4 12:22:00 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 12:22:00 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v4] In-Reply-To: References: Message-ID: <3znZR0AjUMCoDETPZqFf8GXO2RGm9gtefN4JUbHhW5s=.8f741179-a1bb-45d3-8e56-750099c176a3@github.com> > I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. > > Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/foreign 88 88 0 0 > > > Note: This PR should be considered as preparation work for AIX which also uses ABIv1. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Split Shift into ShiftLeft and ShiftRight + minor improvements. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15417/files - new: https://git.openjdk.org/jdk/pull/15417/files/430fa018..2f1c6775 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=02-03 Stats: 95 lines in 4 files changed: 41 ins; 19 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/15417.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15417/head:pull/15417 PR: https://git.openjdk.org/jdk/pull/15417 From mdoerr at openjdk.org Mon Sep 4 12:22:04 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 12:22:04 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 07:06:39 GMT, Jorn Vernee wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary imports. > > src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 695: > >> 693: * Negative [shiftAmount] shifts right and converts to int if needed. >> 694: */ >> 695: record ShiftLeft(int shiftAmount, Class type) implements Binding { > > Please split this into 2 binding operators: one for ShiftLeft and another for (arithmetic) ShiftRight, rather than mixing the 2 implementations into a single operator. > > For the right shift you could then also use a positive shift amount, and avoid the double negation that's needed right now. Done. > src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 703: > >> 701: if (last != ((type == long.class) ? long.class : int.class)) >> 702: throw new IllegalArgumentException( >> 703: String.format("Invalid operand type: %s. integral type expected", last)); > > Why not use `SharedUtils.checkType` here? > > Suggestion: > > SharedUtils.checkType(last, type); Done. > src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 711: > >> 709: stack.push(type == long.class ? long.class : int.class); >> 710: } else >> 711: throw new IllegalArgumentException("shiftAmount 0 not supported"); > > Please handle this validation in the static `shiftLeft` method. That's also where we do validation for other binding ops Done. > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 737: > >> 735: cb.i2l(); >> 736: typeStack.pop(); >> 737: typeStack.push(long.class); > > Please use `popType` and `pushType` instead of manipulating the type stack manually. The former also does some verification. This should happen along every control path. Even if the binding is 1-to-1 (like this one) and doesn't change the type of the value, this would validate that the input type is correct, and make sure that any bugs are caught early. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314872201 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314871165 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314871596 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314871489 From mdoerr at openjdk.org Mon Sep 4 12:22:55 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 12:22:55 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 07:26:36 GMT, Jorn Vernee wrote: > Sorry for the delay, I've been on vacation. No problem. Hope you had a good time! Thanks for your feedback. > src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 398: > >> 396: bindings.add(Binding.cast(type, int.class)); >> 397: type = int.class; >> 398: } > > Part of the casts are handled here with explicit cast bindings, but the widening from int -> long, and narrowing from long -> int are handled implicitly as part of the ShiftLeft implementation. I'd much prefer if all the type conversions are handled with explicit cast bindings. This would also semantically simplify the shift operator, since it would just handle the actual shifting. I guess we would need to add additional bindings for that? Is is worth adding more just for a big endian corner case? Or can that be done with the existing ones? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1705174117 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314874972 From duke at openjdk.org Mon Sep 4 12:35:57 2023 From: duke at openjdk.org (David Schlosnagle) Date: Mon, 4 Sep 2023 12:35:57 GMT Subject: RFR: 8308804: Improve UUID.randomUUID performance with bulk/scalable PRNG access [v7] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 09:37:29 GMT, Aleksey Shipilev wrote: >> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization. >> >> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic. >> >> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. >> >> >> Benchmark Mode Cnt Score Error Units >> >> ### AArch64 (m6g.4xlarge, Graviton, 16 cores) >> >> # Before >> UUIDRandomBench.single thrpt 15 3.545 ? 0.058 ops/us >> UUIDRandomBench.max thrpt 15 1.832 ? 0.059 ops/us ; negative scaling >> >> # After >> UUIDRandomBench.single thrpt 15 4.823 ? 0.023 ops/us >> UUIDRandomBench.max thrpt 15 6.561 ? 0.054 ops/us ; positive scaling, ~1.5x >> >> ### x86_64 (c6.8xlarge, Xeon, 18 cores) >> >> # Before >> UUIDRandomBench.single thrpt 15 2.710 ? 0.038 ops/us >> UUIDRandomBench.max thrpt 15 1.880 ? 0.029 ops/us ; negative scaling >> >> # After >> Benchmark Mode Cnt Score Error Units >> UUIDRandomBench.single thrpt 15 3.109 ? 0.026 ops/us >> UUIDRandomBench.max thrpt 15 3.561 ? 0.071 ops/us ; positive scaling, ~1.2x >> >> >> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout. >> >> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources: >> >> >> Benchmark Mode Cnt Score Error Units >> >> ### x86_64 (c6.8xlarge, Xeon, 18 cores) >> >> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")` >> UUIDRandomBench.single thrpt ... > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Revert test changes > - Merge branch 'master' into JDK-8308804-uuid-buffers > - Simplify clinit > - Remove the properties > - Swap lsb/msb > - Fine-tune exceptions > - Handle privileged properties > - Use ByteArray to convert. Do version/variant preparations straight on locals. Move init out of optimistic lock section. > - More touchups > - Comment updates > - ... and 3 more: https://git.openjdk.org/jdk/compare/4460429d...fd7eaa1a I see this PR was closed out as stale and not integrated. I am curious if there is anything I could do to help push this over the line. As highlighted by @shipilev in the PR description, UUID generation is often a critical component of some systems and contention on SecureRandom can become a scalability bottleneck that I would love to reduce. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14135#issuecomment-1705192263 From jvernee at openjdk.org Mon Sep 4 12:38:43 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 12:38:43 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 12:19:42 GMT, Martin Doerr wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 398: >> >>> 396: bindings.add(Binding.cast(type, int.class)); >>> 397: type = int.class; >>> 398: } >> >> Part of the casts are handled here with explicit cast bindings, but the widening from int -> long, and narrowing from long -> int are handled implicitly as part of the ShiftLeft implementation. I'd much prefer if all the type conversions are handled with explicit cast bindings. This would also semantically simplify the shift operator, since it would just handle the actual shifting. > > I guess we would need to add additional bindings for that? Is is worth adding more just for a big endian corner case? Or can that be done with the existing ones? A `Cast` case for int -> long and long -> int would need to be added. Given the existing setup, that should only be a few lines of code for each. (See e.g. for int -> long https://github.com/openjdk/jdk/compare/master...JornVernee:jdk:I2L). I don't think the cost is that high. > Is is worth adding more just for a big endian corner case? I think it's worth it in order to have a cleaner contract for the shift ops, should we want to use them for anything else in the future, but also just to make them easier to understand for future readers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314892030 From jvernee at openjdk.org Mon Sep 4 12:47:41 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 12:47:41 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v4] In-Reply-To: <3znZR0AjUMCoDETPZqFf8GXO2RGm9gtefN4JUbHhW5s=.8f741179-a1bb-45d3-8e56-750099c176a3@github.com> References: <3znZR0AjUMCoDETPZqFf8GXO2RGm9gtefN4JUbHhW5s=.8f741179-a1bb-45d3-8e56-750099c176a3@github.com> Message-ID: On Mon, 4 Sep 2023 12:22:00 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Split Shift into ShiftLeft and ShiftRight + minor improvements. src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 736: > 734: cb.i2l(); > 735: popType(int.class); > 736: pushType(long.class); These should happen along every code path, so, also in the case where the input type is `long`. This will help catch cases where a previous binding left something else than a `long` on the type stack. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1314900942 From pminborg at openjdk.org Mon Sep 4 13:03:39 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 4 Sep 2023 13:03:39 GMT Subject: RFR: 8315454: Add a way to create an immutable snapshot of a BitSet [v5] In-Reply-To: References: Message-ID: > This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: > > PoolReader (6) > URLEncoder (1) - Updated in this PR > HtmlTree (2) > > More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. > > Initial benchmarks with the URLEncoder show encouraging results: > > > Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% > URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Update test/jdk/java/util/BitSet/ImmutableBitSet.java Co-authored-by: Claes Redestad - Remove factory check and add copyright message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15530/files - new: https://git.openjdk.org/jdk/pull/15530/files/6f80e0b6..80b5aacf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15530&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15530&range=03-04 Stats: 32 lines in 2 files changed: 25 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15530.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15530/head:pull/15530 PR: https://git.openjdk.org/jdk/pull/15530 From jvernee at openjdk.org Mon Sep 4 14:21:38 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 14:21:38 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 12:20:52 GMT, Martin Doerr wrote: >> Sorry for the delay, I've been on vacation. > >> Sorry for the delay, I've been on vacation. > > No problem. Hope you had a good time! Thanks for your feedback. @TheRealMDoerr We've been discussing the shifts in order to wrap our heads around it, and we've ended up with this diagram in order to try and visualize what happens: Let's say we have a struct with 3 ints: struct Foo { int x; int y; int z; }; If this struct is passed as an argument, then the load of the second 'half' of the struct would look like this: offset : 0 .... 32 ..... 64 ..... 96 .... 128 values : xxxxxxxx|yyyyyyyy|zzzzzzzz|???????? (can't touch bits 96..128) Load int : V +--------+ | | +--------+ | V V In register : ????????|zzzzzzzz (MSBs are 0) Shift left : zzzzzzzz|00000000 (LSBs are zero) Write long : V V Result : xxxxxxxx|yyyyyyyy|zzzzzzzz|00000000 So, the 'Result' is padded at the tail with zeros. Does that seem right? Does it seem useful to add this diagram as a comment somewhere, for us when we come back to this code a year from now? Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1705350592 From redestad at openjdk.org Mon Sep 4 14:27:42 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 4 Sep 2023 14:27:42 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v17] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Fri, 1 Sep 2023 18:40:55 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - remove unused import > - UTF16 & Latin1 use same lookup table > - assert bounds check > - Integer/Long toString test against compact strings > > Co-authored-by: liach > - Adapt endian in pack > > Co-authored-by: liach > - use upper case for static final field > - private static final Unsafe > - code format > - simplify code > - format code & comment > - ... and 6 more: https://git.openjdk.org/jdk/compare/2f7c65ec...0d149fa9 A comment on bounds checks. Before `StringUTF16::getChars(int, int, byte[])` it's explicitly spelled out that the important bounds checks must have been done already: // Used by trusted callers. Assumes all necessary bounds checks have // been done by the caller. This is not spelled out for `Integer/Long.getChars(int/long, int, byte[])` but might as well have been since all the usage thereof are from trusted sources that calculate the indexes to fit the string inside the byte buffer. Perhaps `Integer/Long.getChars` and `PACKED_DIGITS` should all be moved to `java.lang.StringLatin1` and be annotated with the same comment as the equivalent methods in `java.lang.StringUTF16`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1705358539 From mcimadamore at openjdk.org Mon Sep 4 14:32:39 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 4 Sep 2023 14:32:39 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 14:18:44 GMT, Jorn Vernee wrote: > If this struct is passed as an argument, then the load of the second 'half' of the struct would look like this: It would perhaps be cleaner if in the MSB/LSB comments we said: LSBs are zzz...z LSBs are 000...0 (e.g. avoid to refer to MSBs in the first, since those bytes are not exactly zero, they are the padding bytes) > I think it's worth it in order to have a cleaner contract for the shift ops, should we want to use them for anything else in the future, but also just to make them easier to understand for future readers. I agree that having a cleaner contract for the shift binding would prove useful in the long run. If we do that, we can also simplify the binding itself, as it would no longer need an input type? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1705366497 PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1315010943 From jvernee at openjdk.org Mon Sep 4 14:35:39 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 14:35:39 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 14:27:27 GMT, Maurizio Cimadamore wrote: > as it would no longer need an input type? Yes. Then both shift ops would always operate on `long`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1315016599 From mdoerr at openjdk.org Mon Sep 4 14:56:18 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 14:56:18 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 14:33:08 GMT, Jorn Vernee wrote: >>> I think it's worth it in order to have a cleaner contract for the shift ops, should we want to use them for anything else in the future, but also just to make them easier to understand for future readers. >> >> I agree that having a cleaner contract for the shift binding would prove useful in the long run. If we do that, we can also simplify the binding itself, as it would no longer need an input type? > >> as it would no longer need an input type? > > Yes. Then both shift ops would always operate on `long`. I've changed it. Note that I need many more conversions because buffer load/store also use subtypes of `int`. Please take a look at my updated version (after commit number 5). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1315032737 From mdoerr at openjdk.org Mon Sep 4 14:56:18 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 14:56:18 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v4] In-Reply-To: References: <3znZR0AjUMCoDETPZqFf8GXO2RGm9gtefN4JUbHhW5s=.8f741179-a1bb-45d3-8e56-750099c176a3@github.com> Message-ID: On Mon, 4 Sep 2023 12:44:51 GMT, Jorn Vernee wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Split Shift into ShiftLeft and ShiftRight + minor improvements. > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 736: > >> 734: cb.i2l(); >> 735: popType(int.class); >> 736: pushType(long.class); > > These should happen along every code path, so, also in the case where the input type is `long`. This will help catch cases where a previous binding left something else than a `long` on the type stack. Ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1315030542 From mdoerr at openjdk.org Mon Sep 4 14:56:18 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 14:56:18 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: > I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. > > Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/foreign 88 88 0 0 > > > Note: This PR should be considered as preparation work for AIX which also uses ABIv1. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Separate type cast from Shift bindings. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15417/files - new: https://git.openjdk.org/jdk/pull/15417/files/2f1c6775..27c4cc1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=03-04 Stats: 77 lines in 2 files changed: 38 ins; 17 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/15417.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15417/head:pull/15417 PR: https://git.openjdk.org/jdk/pull/15417 From mdoerr at openjdk.org Mon Sep 4 14:57:38 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 14:57:38 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v4] In-Reply-To: <3znZR0AjUMCoDETPZqFf8GXO2RGm9gtefN4JUbHhW5s=.8f741179-a1bb-45d3-8e56-750099c176a3@github.com> References: <3znZR0AjUMCoDETPZqFf8GXO2RGm9gtefN4JUbHhW5s=.8f741179-a1bb-45d3-8e56-750099c176a3@github.com> Message-ID: On Mon, 4 Sep 2023 12:22:00 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Split Shift into ShiftLeft and ShiftRight + minor improvements. Hmm. Do you see a good place for such a comment? Maybe it would be better to use a different size for the last chunk. Maybe three or five Bytes. That's even less straight-forward. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1705403519 From jvernee at openjdk.org Mon Sep 4 15:02:44 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 15:02:44 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: <5YofjqTIMfvaLMpp4dLPcmdtPGPn7RZaY3Go0iUkwpI=.8e7fac92-e1ec-4916-b65c-482e24e46a84@github.com> On Mon, 4 Sep 2023 14:56:18 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Separate type cast from Shift bindings. src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 425: > 423: if (type == int.class || isSubIntType(type)) { > 424: bindings.add(Binding.cast(type, long.class)); > 425: type = long.class; This line seems redundant now (`type` is not used below). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1315035355 From jvernee at openjdk.org Mon Sep 4 15:02:40 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 15:02:40 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v4] In-Reply-To: References: <3znZR0AjUMCoDETPZqFf8GXO2RGm9gtefN4JUbHhW5s=.8f741179-a1bb-45d3-8e56-750099c176a3@github.com> Message-ID: On Mon, 4 Sep 2023 14:54:05 GMT, Martin Doerr wrote: > Do you see a good place for such a comment? PPC CallArranger seems like a good place to me. We have a similar explanation comment in the AArch64 CallArranger. > Maybe it would be better to use a different size for the last chunk. Maybe three or five Bytes. That's even less straight-forward. Does the size matter that much? It just changes the shift amount right? Could use `short` as type for `z` as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1705409739 From jvernee at openjdk.org Mon Sep 4 15:02:41 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 15:02:41 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 14:50:37 GMT, Martin Doerr wrote: >>> as it would no longer need an input type? >> >> Yes. Then both shift ops would always operate on `long`. > > I've changed it. Note that I need many more conversions because buffer load/store also use subtypes of `int`. Please take a look at my updated version (after commit number 5). Thanks, your changes look great. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1315040087 From jvernee at openjdk.org Mon Sep 4 15:38:19 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 15:38:19 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 14:56:18 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Separate type cast from Shift bindings. Latest version looks great! I've started a CI job as well. Will approve when that comes back green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1705454528 From mdoerr at openjdk.org Mon Sep 4 15:38:19 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 15:38:19 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v6] In-Reply-To: References: Message-ID: > I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. > > Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/foreign 88 88 0 0 > > > Note: This PR should be considered as preparation work for AIX which also uses ABIv1. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Add comment. Remove obsolete assignment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15417/files - new: https://git.openjdk.org/jdk/pull/15417/files/27c4cc1b..d493950d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=04-05 Stats: 16 lines in 2 files changed: 15 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15417.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15417/head:pull/15417 PR: https://git.openjdk.org/jdk/pull/15417 From mdoerr at openjdk.org Mon Sep 4 15:38:19 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 15:38:19 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 14:56:18 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Separate type cast from Shift bindings. Thank you! I have added an example to the CallArranger. Please take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1705453151 From mdoerr at openjdk.org Mon Sep 4 15:38:19 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 15:38:19 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v5] In-Reply-To: <5YofjqTIMfvaLMpp4dLPcmdtPGPn7RZaY3Go0iUkwpI=.8e7fac92-e1ec-4916-b65c-482e24e46a84@github.com> References: <5YofjqTIMfvaLMpp4dLPcmdtPGPn7RZaY3Go0iUkwpI=.8e7fac92-e1ec-4916-b65c-482e24e46a84@github.com> Message-ID: On Mon, 4 Sep 2023 14:53:33 GMT, Jorn Vernee wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> Separate type cast from Shift bindings. > > src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 425: > >> 423: if (type == int.class || isSubIntType(type)) { >> 424: bindings.add(Binding.cast(type, long.class)); >> 425: type = long.class; > > This line seems redundant now (`type` is not used below). Good catch! Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1315066254 From mdoerr at openjdk.org Mon Sep 4 15:44:40 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 15:44:40 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v6] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 15:38:19 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Add comment. Remove obsolete assignment. Thanks! `test/jdk/java/foreign` tests have passed on linux x86_64, ppc64 and ppc64le on my side. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1705465170 From duke at openjdk.org Mon Sep 4 15:50:12 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 4 Sep 2023 15:50:12 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v18] In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: <7gDNUkXKT4Kx5FOvsQvLzV6_a3rL6swMx285GFU2Y2w=.7584c2a9-202c-46c7-b879-69d4cd7efb28@github.com> > Optimization for: > Integer.toString > Long.toString > StringBuilder#append(int) > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.Integers.toString*" > make test TEST="micro:java.lang.Longs.toString*" > make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op > -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op > -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) > +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) > +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) > > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op > -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) > +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op > > +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) > > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op > -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op > -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ? 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... ??? has updated the pull request incrementally with one additional commit since the last revision: move Integer/Long.getChars to StringLatin1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14699/files - new: https://git.openjdk.org/jdk/pull/14699/files/0d149fa9..ed1c58bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=16-17 Stats: 339 lines in 6 files changed: 162 ins; 164 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699 PR: https://git.openjdk.org/jdk/pull/14699 From redestad at openjdk.org Mon Sep 4 15:50:37 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 4 Sep 2023 15:50:37 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v18] In-Reply-To: <7gDNUkXKT4Kx5FOvsQvLzV6_a3rL6swMx285GFU2Y2w=.7584c2a9-202c-46c7-b879-69d4cd7efb28@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> <7gDNUkXKT4Kx5FOvsQvLzV6_a3rL6swMx285GFU2Y2w=.7584c2a9-202c-46c7-b879-69d4cd7efb28@github.com> Message-ID: <2n7XFHvDmt6otH1ULSD6oLSopSaKgm9pm8mpg-_mE-4=.d0602bec-bb79-4555-b533-e69fd8d31204@github.com> On Mon, 4 Sep 2023 15:50:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > move Integer/Long.getChars to StringLatin1 src/java.base/share/classes/java/lang/StringLatin1.java line 119: > 117: return ret; > 118: } > 119: I think this is an improvement since it better groups these latin1 formatting methods together. Add a copy of the comment from `StringUTF16` about bound-checking here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1315079267 From jvernee at openjdk.org Mon Sep 4 15:54:41 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 15:54:41 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v10] 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 five additional commits since the last revision: - 8315096: Allowed access modes in memory segment should depend on layout alignment Reviewed-by: psandoz - Add missing @implSpec to AddressLayout Reviewed-by: pminborg - Fix misc typos in FFM API javadoc Reviewed-by: jvernee - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two) Reviewed-by: pminborg - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle Reviewed-by: jvernee ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/ea3daaed..de3e7479 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=08-09 Stats: 306 lines in 6 files changed: 218 ins; 12 del; 76 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 Mon Sep 4 15:55:02 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Sep 2023 15:55:02 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v9] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 11:33:30 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 unsupported linker test Adding a few more minor fixes: - Clarifying javadoc comments wrt which exceptions are thrown by handles derived from layouts: https://github.com/openjdk/panama-foreign/pull/869 & https://github.com/openjdk/panama-foreign/pull/872 - Fixing typos: https://github.com/openjdk/panama-foreign/pull/873 - Missing `@implspec` in AddressLayout: https://github.com/openjdk/panama-foreign/pull/877 - Correct the exception that is thrown for an unsupported access using a var handle: https://github.com/openjdk/panama-foreign/pull/876 Only the latter change is really significant (see the original PR) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1705475550 From duke at openjdk.org Mon Sep 4 16:00:05 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Mon, 4 Sep 2023 16:00:05 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v19] In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: > Optimization for: > Integer.toString > Long.toString > StringBuilder#append(int) > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.Integers.toString*" > make test TEST="micro:java.lang.Longs.toString*" > make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op > -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op > -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) > +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) > +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) > > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op > -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) > +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op > > +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) > > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op > -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op > -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ? 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... ??? has updated the pull request incrementally with one additional commit since the last revision: add comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14699/files - new: https://git.openjdk.org/jdk/pull/14699/files/ed1c58bb..f37ed8a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=17-18 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699 PR: https://git.openjdk.org/jdk/pull/14699 From redestad at openjdk.org Mon Sep 4 16:18:41 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 4 Sep 2023 16:18:41 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v19] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Mon, 4 Sep 2023 16:00:05 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > add comments Looks good to me. Please be patient and wait for @RogerRiggs to approve this, too (today is a holiday in the US) src/java.base/share/classes/java/lang/StringUTF16.java line 1534: > 1532: */ > 1533: static int getChars(int i, int index, byte[] buf) { > 1534: // Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. Now these are a bit redundant since these methods are surrounded by a comment to the same effect. I prefer inline comments like these, but we should avoid having both. ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14699#pullrequestreview-1609789061 PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1315096657 From mdoerr at openjdk.org Mon Sep 4 19:57:37 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 19:57:37 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 07:26:37 GMT, Aleksey Shipilev wrote: > Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. src/java.base/share/classes/jdk/internal/util/Architecture.java line 164: > 162: public static boolean isPPC() { > 163: return PlatformProps.TARGET_ARCH_IS_PPC; > 164: } Maybe `isPPC32()` would be a better name (also `PPC32` above). Note that hotspot uses `PPC` for all PPC platforms and has the more specific macros `PPC32` and `PPC64`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15556#discussion_r1315180685 From mdoerr at openjdk.org Mon Sep 4 21:17:06 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 4 Sep 2023 21:17:06 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v7] In-Reply-To: References: Message-ID: > I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. > > Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/foreign 88 88 0 0 > > > Note: This PR should be considered as preparation work for AIX which also uses ABIv1. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Add comments. Simplify condition. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15417/files - new: https://git.openjdk.org/jdk/pull/15417/files/d493950d..9c06646b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=05-06 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15417.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15417/head:pull/15417 PR: https://git.openjdk.org/jdk/pull/15417 From duke at openjdk.org Tue Sep 5 00:10:12 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 00:10:12 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: > Optimization for: > Integer.toString > Long.toString > StringBuilder#append(int) > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.Integers.toString*" > make test TEST="micro:java.lang.Longs.toString*" > make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op > -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op > -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) > +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) > +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) > > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op > -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) > +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op > > +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) > > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op > -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op > -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ? 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... ??? has updated the pull request incrementally with one additional commit since the last revision: update copyright date info ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14699/files - new: https://git.openjdk.org/jdk/pull/14699/files/f37ed8a5..18904a93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=18-19 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699 PR: https://git.openjdk.org/jdk/pull/14699 From duke at openjdk.org Tue Sep 5 00:10:13 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 00:10:13 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v19] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Mon, 4 Sep 2023 16:13:53 GMT, Claes Redestad wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> add comments > > src/java.base/share/classes/java/lang/StringUTF16.java line 1534: > >> 1532: */ >> 1533: static int getChars(int i, int index, byte[] buf) { >> 1534: // Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. > > Now these are a bit redundant since these methods are surrounded by a comment to the same effect. I prefer inline comments like these, but we should avoid having both. Comments are redundant, but I can't find a solution ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1315237072 From duke at openjdk.org Tue Sep 5 01:49:33 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 01:49:33 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v8] In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: > [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.util.UUIDBench.toString" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) > > > > ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) > * cpu : aliyun yitian 710 (aarch64) > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) > > > ## 4. MacBookPro M1 Pro > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) > > > ## 5. Orange Pi 5 Plus > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us > > +Benchmark (size) Mode Cnt Score Error Units (PR) > +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) ??? has updated the pull request incrementally with one additional commit since the last revision: use ByteArrayLittleEndian ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14745/files - new: https://git.openjdk.org/jdk/pull/14745/files/d6bb2725..25cf0144 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=06-07 Stats: 78 lines in 2 files changed: 1 ins; 49 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/14745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14745/head:pull/14745 PR: https://git.openjdk.org/jdk/pull/14745 From duke at openjdk.org Tue Sep 5 01:49:35 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 01:49:35 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v6] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> <90SkXhk3AttjkCDs26NYiysShCkPfCyyi2mYeY432Mw=.c9bac184-e20c-4533-a288-fdb70eaa0a73@github.com> Message-ID: On Sat, 8 Jul 2023 07:14:12 GMT, ??? wrote: >> src/java.base/share/classes/java/util/HexDigits.java line 44: >> >>> 42: * 0 -> '00' -> ('0' << 8) | '0' -> 0x3030 >>> 43: * 1 -> '01' -> ('0' << 8) | '1' -> 0x3130 >>> 44: * 2 -> '02' -> ('0' << 8) | '2' -> 0x3230 >> >> The description of the array content does not need to be exhaustive; just sufficient to understand how it is indexed and the meaning of the values. > > The comment is already there, I think the value on the right is easier to understand in hexadecimal comment has been removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1315275178 From duke at openjdk.org Tue Sep 5 02:46:21 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 02:46:21 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v9] In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: > [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.util.UUIDBench.toString" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) > > > > ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) > * cpu : aliyun yitian 710 (aarch64) > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) > > > ## 4. MacBookPro M1 Pro > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) > > > ## 5. Orange Pi 5 Plus > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us > > +Benchmark (size) Mode Cnt Score Error Units (PR) > +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into optimization_for_uuid_to_string - use ByteArrayLittleEndian - fix typo - code style - Explain the rationale Co-authored-by: liach - private static final Unsafe - revert to the previous version - Merge pull request #1 from liachmodded/optimization_for_uuid_to_string Suggested HexDigits change - Suggested HexDigits change - use big endian - ... and 1 more: https://git.openjdk.org/jdk/compare/97e85d94...69962433 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14745/files - new: https://git.openjdk.org/jdk/pull/14745/files/25cf0144..69962433 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=07-08 Stats: 148919 lines in 2866 files changed: 61136 ins; 70985 del; 16798 mod Patch: https://git.openjdk.org/jdk/pull/14745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14745/head:pull/14745 PR: https://git.openjdk.org/jdk/pull/14745 From liach at openjdk.org Tue Sep 5 03:47:55 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Sep 2023 03:47:55 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v9] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: <6BT7QN09Tnm_1SEy30o8PRD99D9l1oPKoH-1uoyuDr0=.76931b2e-271c-4f2b-a5b9-4999dd717a2f@github.com> On Tue, 5 Sep 2023 02:46:21 GMT, ??? wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) >> >> >> >> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) > > ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into optimization_for_uuid_to_string > - use ByteArrayLittleEndian > - fix typo > - code style > - Explain the rationale > > Co-authored-by: liach > - private static final Unsafe > - revert to the previous version > - Merge pull request #1 from liachmodded/optimization_for_uuid_to_string > > Suggested HexDigits change > - Suggested HexDigits change > - use big endian > - ... and 1 more: https://git.openjdk.org/jdk/compare/ac7b7229...69962433 src/java.base/share/classes/java/util/HexDigits.java line 68: > 66: > 67: /** > 68: * Return a big-endian packed integer for the 4 ASCII bytes for an input unsigned 2-byte integer. Suggestion: * Returns a little-endian packed integer for the 4 ASCII bytes for an input unsigned 2-byte integer. src/java.base/share/classes/java/util/HexDigits.java line 77: > 75: > 76: /** > 77: * Return a big-endian packed long for the 8 ASCII bytes for an input unsigned 4-byte integer. Suggestion: * Returns a little-endian packed long for the 8 ASCII bytes for an input unsigned 4-byte integer. src/java.base/share/classes/java/util/UUID.java line 494: > 492: buf, > 493: 24, > 494: HexDigits.packDigits(((int) (lsb >> 40)), (int) (lsb >> 32), ((int) lsb) >> 24, ((int) lsb) >> 16)); Suggestion: HexDigits.packDigits((int) (lsb >> 40), (int) (lsb >> 32), ((int) lsb) >> 24, ((int) lsb) >> 16)); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1315331223 PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1315331130 PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1315314460 From duke at openjdk.org Tue Sep 5 04:37:03 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 04:37:03 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v10] In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: <5V04yA_VtpcrZqWeZdrvWsaZ5VNdIZFXSPWVGTdJw00=.fdd8a6e7-0ea1-4511-af9c-1f2806a82741@github.com> > [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.util.UUIDBench.toString" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) > > > > ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) > * cpu : aliyun yitian 710 (aarch64) > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) > > > ## 4. MacBookPro M1 Pro > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) > > > ## 5. Orange Pi 5 Plus > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us > > +Benchmark (size) Mode Cnt Score Error Units (PR) > +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) ??? has updated the pull request incrementally with two additional commits since the last revision: - remove redundant parentheses - fix java doc, big-endian -> little-endian ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14745/files - new: https://git.openjdk.org/jdk/pull/14745/files/69962433..3f6d35df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=08-09 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14745/head:pull/14745 PR: https://git.openjdk.org/jdk/pull/14745 From duke at openjdk.org Tue Sep 5 05:52:42 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 05:52:42 GMT Subject: RFR: 8315585: Optimization for decimal to string In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 04:58:08 GMT, ??? wrote: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... @liach can you help me to review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1705981814 From liach at openjdk.org Tue Sep 5 06:12:47 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Sep 2023 06:12:47 GMT Subject: RFR: 8315585: Optimization for decimal to string In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 04:58:08 GMT, ??? wrote: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... src/java.base/share/classes/java/math/BigInteger.java line 4104: > 4102: byte[] buf = smallToString(signum < 0, abs); > 4103: try { > 4104: return BigDecimal.jla.newStringNoRepl(buf, StandardCharsets.ISO_8859_1); The usages of `BigDecimal.jla` and its String computation methods may trigger initialization of BigDecimal when using BigInteger. I recommend moving these string computation utilities and the jla field to a new package-private class within java.math (or a new class in jdk.internal.math package) to prevent initializing BigDecimal unnecessarily. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1315408192 From pminborg at openjdk.org Tue Sep 5 06:46:01 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 5 Sep 2023 06:46:01 GMT Subject: Integrated: 8315454: Add a way to create an immutable snapshot of a BitSet In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 08:21:13 GMT, Per Minborg wrote: > This PR proposes adding a new method to BitSet that provides an immutable snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit directly from constant-folding of BitSets: > > PoolReader (6) > URLEncoder (1) - Updated in this PR > HtmlTree (2) > > More over, the implementation of the predicate is @ValueBased and this would provide additional benefits in the future. > > Initial benchmarks with the URLEncoder show encouraging results: > > > Name (encodeChars) (maxLength) (unchanged) Cnt Base Error Test Error Unit Diff% > URLEncodeDecode.testEncodeUTF8 6 1024 0 15 2,371 ? 0,016 2,073 ? 0,184 ms/op 12,6% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 75 15 1,772 ? 0,013 1,387 ? 0,032 ms/op 21,8% (p = 0,000*) > URLEncodeDecode.testEncodeUTF8 6 1024 100 15 1,230 ? 0,009 1,140 ? 0,011 ms/op 7,3% (p = 0,000*) This pull request has now been integrated. Changeset: f2922682 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/f2922682688a40529df269e1551246ac8da5d7ee Stats: 194 lines in 3 files changed: 181 ins; 1 del; 12 mod 8315454: Add a way to create an immutable snapshot of a BitSet Co-authored-by: Claes Redestad Reviewed-by: redestad ------------- PR: https://git.openjdk.org/jdk/pull/15530 From jlahoda at openjdk.org Tue Sep 5 08:20:42 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 5 Sep 2023 08:20:42 GMT Subject: RFR: 8312491: Update Classfile API snippets and examples [v11] In-Reply-To: <9AeWVRa_vXQkxUREwK8DnJYAmpDRkFoIQ21Y9_FYMP4=.537b8e72-58c3-4357-89b9-7db96756516a@github.com> References: <9AeWVRa_vXQkxUREwK8DnJYAmpDRkFoIQ21Y9_FYMP4=.537b8e72-58c3-4357-89b9-7db96756516a@github.com> Message-ID: On Fri, 1 Sep 2023 12:13:05 GMT, Adam Sotona wrote: >> This pull request updates Classfile API snippets and examples and adds missing javadoc. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > added notes to attributes Looks like an improvement to me! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14968#pullrequestreview-1610489626 From lucy at openjdk.org Tue Sep 5 08:22:41 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 5 Sep 2023 08:22:41 GMT Subject: RFR: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 In-Reply-To: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> References: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> Message-ID: On Fri, 1 Sep 2023 07:22:12 GMT, Matthias Baesken wrote: > on some RHEL Linux 8.X machines , we run into errors in test tools/jpackage/share/RuntimePackageTest.java#id0 , error can be seen below. > It looks like these errors occur when running the jtreg tests with higher concurrency, I did not see them when running just the single test. > > When adding some test output , we see the 2 top install dirs below (1 is expected, not 2) : > ./test/unpacked-rpm/opt > ./test/unpacked-rpm/usr > > error output : > > java.lang.AssertionError: Expected [1]. Actual [2]: Check the package has 1 top installation directories > at jdk.jpackage.test.TKit.error(TKit.java:273) > at jdk.jpackage.test.TKit.assertEquals(TKit.java:576) > at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:705) > at jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$3(PackageTest.java:635) > at java.base/java.util.Optional.ifPresent(Optional.java:178) > at jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:633) > at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:592) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) > at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) > at java.base/java.lang.Iterable.forEach(Iterable.java:75) > at jdk.jpackage.test.PackageTest.lambda$runActions$24(PackageTest.java:381) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.lambda$runActions$25(PackageTest.java:380) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.runActions(PackageTest.java:379) > at jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) > at RuntimePackageTest.test(RuntimePackageTest.java:83) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) > at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) > at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) > at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708) > at java.base/jav... LGTM. Thanks for fixing. The add'l output doesn't fix anything, but may be helpful in the future. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15528#pullrequestreview-1610495096 From clanger at openjdk.org Tue Sep 5 08:34:48 2023 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 5 Sep 2023 08:34:48 GMT Subject: Integrated: 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows when run as user with Administrator privileges In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 09:54:43 GMT, Christoph Langer wrote: > On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible. This pull request has now been integrated. Changeset: 69c9ec92 Author: Christoph Langer URL: https://git.openjdk.org/jdk/commit/69c9ec92d04a399946b2157690a1dc3fec517329 Stats: 46 lines in 1 file changed: 31 ins; 10 del; 5 mod 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows when run as user with Administrator privileges Reviewed-by: mbaesken, azeller ------------- PR: https://git.openjdk.org/jdk/pull/15222 From jvernee at openjdk.org Tue Sep 5 08:43:48 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 5 Sep 2023 08:43:48 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v7] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 21:17:06 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Add comments. Simplify condition. Just some known failures in CI ([1]). So, this is good to go from my perspective. [1]: https://bugs.openjdk.org/browse/JDK-8315646 ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15417#pullrequestreview-1610536541 From mbaesken at openjdk.org Tue Sep 5 08:51:39 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 5 Sep 2023 08:51:39 GMT Subject: RFR: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 In-Reply-To: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> References: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> Message-ID: On Fri, 1 Sep 2023 07:22:12 GMT, Matthias Baesken wrote: > on some RHEL Linux 8.X machines , we run into errors in test tools/jpackage/share/RuntimePackageTest.java#id0 , error can be seen below. > It looks like these errors occur when running the jtreg tests with higher concurrency, I did not see them when running just the single test. > > When adding some test output , we see the 2 top install dirs below (1 is expected, not 2) : > ./test/unpacked-rpm/opt > ./test/unpacked-rpm/usr > > error output : > > java.lang.AssertionError: Expected [1]. Actual [2]: Check the package has 1 top installation directories > at jdk.jpackage.test.TKit.error(TKit.java:273) > at jdk.jpackage.test.TKit.assertEquals(TKit.java:576) > at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:705) > at jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$3(PackageTest.java:635) > at java.base/java.util.Optional.ifPresent(Optional.java:178) > at jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:633) > at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:592) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) > at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) > at java.base/java.lang.Iterable.forEach(Iterable.java:75) > at jdk.jpackage.test.PackageTest.lambda$runActions$24(PackageTest.java:381) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.lambda$runActions$25(PackageTest.java:380) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.runActions(PackageTest.java:379) > at jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) > at RuntimePackageTest.test(RuntimePackageTest.java:83) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) > at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) > at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) > at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708) > at java.base/jav... Hi Lutz, thanks for the review ! I'll wait a little more maybe Alexey has still something to comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15528#issuecomment-1706202637 From asotona at openjdk.org Tue Sep 5 08:51:47 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 5 Sep 2023 08:51:47 GMT Subject: Integrated: 8312491: Update Classfile API snippets and examples In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 09:37:10 GMT, Adam Sotona wrote: > This pull request updates Classfile API snippets and examples and adds missing javadoc. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 744b3970 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/744b3970f92ff5942b5ad942831053b24367e67f Stats: 3405 lines in 62 files changed: 3321 ins; 20 del; 64 mod 8312491: Update Classfile API snippets and examples Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/14968 From asotona at openjdk.org Tue Sep 5 08:57:12 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 5 Sep 2023 08:57:12 GMT Subject: RFR: 8313452: Improve Classfile API attributes handling safety Message-ID: This PR improved Classfile API attributes handling safety by introduction of attribute stability indicator and by extension of UnknownAttributesOption to more general AttributesProcessingOption. ------------- Commit messages: - fixed remaining listFromTrustedArrayNullsAllowed calls to listFromTrustedArray - added test for AttributesProcessingOption.DROP_UNKNOWN_ATTRIBUTES - re-added AttributeStability.UNKNOWN - dropped AttributeStability.UNKNOWN - 8313452: Improve Classfile API attributes handling safety - fixing javadoc - fixing javadoc - fixing javadoc - fixing javadoc - fixing javadoc - ... and 3 more: https://git.openjdk.org/jdk/compare/37c756a7...350588bd Changes: https://git.openjdk.org/jdk/pull/15101/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15101&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313452 Stats: 3753 lines in 37 files changed: 3583 ins; 44 del; 126 mod Patch: https://git.openjdk.org/jdk/pull/15101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15101/head:pull/15101 PR: https://git.openjdk.org/jdk/pull/15101 From mdoerr at openjdk.org Tue Sep 5 09:00:42 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 5 Sep 2023 09:00:42 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 14:30:06 GMT, Maurizio Cimadamore wrote: >> @TheRealMDoerr We've been discussing the shifts in order to wrap our heads around it, and we've ended up with this diagram in order to try and visualize what happens: >> >> Let's say we have a struct with 3 ints: >> >> >> struct Foo { >> int x; >> int y; >> int z; >> }; >> >> >> If this struct is passed as an argument, then the load of the second 'half' of the struct would look like this: >> >> >> offset : 0 .... 32 ..... 64 ..... 96 .... 128 >> values : xxxxxxxx|yyyyyyyy|zzzzzzzz|???????? (can't touch bits 96..128) >> Load int : V +--------+ >> | | >> +--------+ | >> V V >> In register : ????????|zzzzzzzz (MSBs are 0) >> Shift left : zzzzzzzz|00000000 (LSBs are zero) >> Write long : V V >> Result : xxxxxxxx|yyyyyyyy|zzzzzzzz|00000000 >> >> >> So, the 'Result' is padded at the tail with zeros. >> >> Does that seem right? Does it seem useful to add this diagram as a comment somewhere, for us when we come back to this code a year from now? Thanks > >> If this struct is passed as an argument, then the load of the second 'half' of the struct would look like this: > > It would perhaps be cleaner if in the MSB/LSB comments we said: > > LSBs are zzz...z > LSBs are 000...0 > > (e.g. avoid to refer to MSBs in the first, since those bytes are not exactly zero, they are the padding bytes) @mcimadamore: May I ask you or somebody else from the Panama team to provide a 2nd review? This PR requires Panama knowledge, not really PPC knowledge. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1706217722 From pminborg at openjdk.org Tue Sep 5 09:01:07 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 5 Sep 2023 09:01:07 GMT Subject: RFR: 8314260: Unable to load system libraries on Windows when using a SecurityManager Message-ID: This PR proposes to read the system environment variable "SystemRoot" using a privileged operation so it will work in the event a default SecurityManager is in place. As the `SecurityManager` is deprecated for removal, no support methods were added for reading environmental variables. ------------- Commit messages: - Use privilidged access for getenv call Changes: https://git.openjdk.org/jdk/pull/15564/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15564&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314260 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15564.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15564/head:pull/15564 PR: https://git.openjdk.org/jdk/pull/15564 From pminborg at openjdk.org Tue Sep 5 09:38:17 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 5 Sep 2023 09:38:17 GMT Subject: RFR: 8314260: Unable to load system libraries on Windows when using a SecurityManager [v2] In-Reply-To: References: Message-ID: > This PR proposes to read the system environment variable "SystemRoot" using a privileged operation so it will work in the event a default SecurityManager is in place. > > As the `SecurityManager` is deprecated for removal, no support methods were added for reading environmental variables. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add a SecurityManager for TestLinker ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15564/files - new: https://git.openjdk.org/jdk/pull/15564/files/6b8e4299..74c3d2c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15564&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15564&range=00-01 Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15564.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15564/head:pull/15564 PR: https://git.openjdk.org/jdk/pull/15564 From duke at openjdk.org Tue Sep 5 09:39:40 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 5 Sep 2023 09:39:40 GMT Subject: RFR: 8314260: Unable to load system libraries on Windows when using a SecurityManager [v2] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 09:38:17 GMT, Per Minborg wrote: >> This PR proposes to read the system environment variable "SystemRoot" using a privileged operation so it will work in the event a default SecurityManager is in place. >> >> As the `SecurityManager` is deprecated for removal, no support methods were added for reading environmental variables. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add a SecurityManager for TestLinker test/jdk/java/foreign/TestLinker.java line 30: > 28: * @modules java.base/jdk.internal.foreign > 29: * @run testng/othervm/policy=security.policy > 30: * -Djava.security.manager=default TestLinker This?test should?also be?run?without a?`SecurityManager`?installed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15564#discussion_r1315645246 From duke at openjdk.org Tue Sep 5 10:10:11 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 10:10:11 GMT Subject: RFR: 8315585: Optimization for decimal to string [v2] In-Reply-To: References: Message-ID: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request incrementally with one additional commit since the last revision: BigInteger use a separate jla ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/9846ff90..97e4f7db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=00-01 Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From asotona at openjdk.org Tue Sep 5 11:07:03 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 5 Sep 2023 11:07:03 GMT Subject: RFR: 8315541: Classfile API TypeAnnotation.TargetInfo factory methods accept null labels Message-ID: This patch performs null checks in to refuse null labels in TypeAnnotation.TargetInfo implementations. Please review. Thanks, Adam ------------- Commit messages: - 8315541: Classfile API TypeAnnotation.TargetInfo factory methods accept null labels Changes: https://git.openjdk.org/jdk/pull/15565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15565&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315541 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15565/head:pull/15565 PR: https://git.openjdk.org/jdk/pull/15565 From pminborg at openjdk.org Tue Sep 5 11:56:19 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 5 Sep 2023 11:56:19 GMT Subject: RFR: 8314260: Unable to load system libraries on Windows when using a SecurityManager [v3] In-Reply-To: References: Message-ID: > This PR proposes to read the system environment variable "SystemRoot" using a privileged operation so it will work in the event a default SecurityManager is in place. > > As the `SecurityManager` is deprecated for removal, no support methods were added for reading environmental variables. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add extra test run with no SecutityManager ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15564/files - new: https://git.openjdk.org/jdk/pull/15564/files/74c3d2c9..0cc7c381 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15564&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15564&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15564.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15564/head:pull/15564 PR: https://git.openjdk.org/jdk/pull/15564 From pminborg at openjdk.org Tue Sep 5 11:56:20 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 5 Sep 2023 11:56:20 GMT Subject: RFR: 8314260: Unable to load system libraries on Windows when using a SecurityManager [v2] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 09:36:59 GMT, ExE Boss wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a SecurityManager for TestLinker > > test/jdk/java/foreign/TestLinker.java line 30: > >> 28: * @modules java.base/jdk.internal.foreign >> 29: * @run testng/othervm/policy=security.policy >> 30: * -Djava.security.manager=default TestLinker > > This?test should?also be?run?without a?`SecurityManager`?installed. Good point ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15564#discussion_r1315782327 From rriggs at openjdk.org Tue Sep 5 13:54:49 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Sep 2023 13:54:49 GMT Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows when run as user with Administrator privileges [v2] In-Reply-To: <6XbXvXBp_UUhj1UNGnSRwCzURb_DhWjX8CPOXJY5OjA=.383899d1-57be-400f-94bc-70b500d8ebfd@github.com> References: <6XbXvXBp_UUhj1UNGnSRwCzURb_DhWjX8CPOXJY5OjA=.383899d1-57be-400f-94bc-70b500d8ebfd@github.com> Message-ID: On Fri, 1 Sep 2023 08:32:20 GMT, Christoph Langer wrote: >> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible. > > Christoph Langer has updated the pull request with a new target base 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: > > - Use System.getProperty(user.name) for the Windows Adminstrators case > - Merge branch 'master' into JDK-8314094 > - JDK-8314094 A bit late due to a US holiday. Looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/15222#pullrequestreview-1611114630 From clanger at openjdk.org Tue Sep 5 14:09:50 2023 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 5 Sep 2023 14:09:50 GMT Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows when run as user with Administrator privileges [v2] In-Reply-To: References: <6XbXvXBp_UUhj1UNGnSRwCzURb_DhWjX8CPOXJY5OjA=.383899d1-57be-400f-94bc-70b500d8ebfd@github.com> Message-ID: On Tue, 5 Sep 2023 13:52:09 GMT, Roger Riggs wrote: > A bit late due to a US holiday. Looks good. Thanks ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15222#issuecomment-1706695064 From asotona at openjdk.org Tue Sep 5 14:25:05 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 5 Sep 2023 14:25:05 GMT Subject: RFR: 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex methods are confusing Message-ID: Classfile API `ConstantPool::entryCount` and `ConstantPool::entryByIndex` methods are confusing and unsafe to use without knowledge of constant pool specification. This patch renames `ConstantPool::entryCount` to `ConstantPool::size` and adds checks to `ConstantPool::entryByIndex` for invalid or unusable indexes. `ConstantPool` newly extends `Iterable` for simplified user iteration over all pool entries. Range checks for invalid index have been added also to `ConstantPoo::bootstrapMethodEntry` methods and several `@jvms` javadoc tags have been added to pool entries. Please review. Thanks, Adam ------------- Commit messages: - 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex is confusing Changes: https://git.openjdk.org/jdk/pull/15567/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15567&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315678 Stats: 100 lines in 27 files changed: 68 ins; 6 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/15567.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15567/head:pull/15567 PR: https://git.openjdk.org/jdk/pull/15567 From mullan at openjdk.org Tue Sep 5 15:20:42 2023 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Sep 2023 15:20:42 GMT Subject: RFR: 8314260: Unable to load system libraries on Windows when using a SecurityManager [v3] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 11:56:19 GMT, Per Minborg wrote: >> This PR proposes to read the system environment variable "SystemRoot" using a privileged operation so it will work in the event a default SecurityManager is in place. >> >> As the `SecurityManager` is deprecated for removal, no support methods were added for reading environmental variables. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add extra test run with no SecutityManager test/jdk/java/foreign/security.policy line 1: > 1: grant { To avoid inadvertently granting these permissions to codebases other than the tests, you should change the grant clause to `grant codebase "file:${test.classes}/" {` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15564#discussion_r1316053185 From asotona at openjdk.org Tue Sep 5 15:25:04 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 5 Sep 2023 15:25:04 GMT Subject: RFR: 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex methods are confusing [v2] In-Reply-To: References: Message-ID: > Classfile API `ConstantPool::entryCount` and `ConstantPool::entryByIndex` methods are confusing and unsafe to use without knowledge of constant pool specification. > This patch renames `ConstantPool::entryCount` to `ConstantPool::size` and adds checks to `ConstantPool::entryByIndex` for invalid or unusable indexes. > `ConstantPool` newly extends `Iterable` for simplified user iteration over all pool entries. > Range checks for invalid index have been added also to `ConstantPoo::bootstrapMethodEntry` methods and several `@jvms` javadoc tags have been added to pool entries. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15567/files - new: https://git.openjdk.org/jdk/pull/15567/files/17c57540..38406b28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15567&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15567&range=00-01 Stats: 8 lines in 4 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15567.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15567/head:pull/15567 PR: https://git.openjdk.org/jdk/pull/15567 From sviswanathan at openjdk.org Tue Sep 5 15:38:50 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 5 Sep 2023 15:38:50 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 @ericcaspole Could you please also review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15230#issuecomment-1706851997 From asotona at openjdk.org Tue Sep 5 15:42:49 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 5 Sep 2023 15:42:49 GMT Subject: RFR: 8313258: RuntimeInvisibleTypeAnnotationsAttribute.annotations() API Index out of Bound error In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 14:18:00 GMT, Chen Liang wrote: >> Classfile API suppose to throw IllegalArgumentException in situations where bytecode offset is out of allowed range. Such situation includes invalid offset parsed from a TypeAnnotation as well as from other CodeAttribute attributes. >> >> This patch throws IAE for invalid bytecode offset when requested Label for the parsed CodeAttribute, so it cover even wider range of cases than mentioned in the bug report. >> >> Please review. >> >> Thanks, >> Adam > > src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 101: > >> 99: public Label getLabel(int bci) { >> 100: if (bci < 0 || bci > codeLength) >> 101: throw new IllegalArgumentException(String.format("Bytecode offset out of range; bci=%d, codeLength=%d", > > Should we get an IAE formatter in `jdk.internal.util.Preconditons` for classfile-specific bound checking, so we can do `Preconditions.checkIndex(bci, codeLength, Preconditions.IAE_FORMATTER);` and share it with other use sites of classfile-specific exceptions. > > In addition, we might move the `new IllegalArgumentException` constructor calls to a utility method in our `Util` class in case we migrate our exceptions to a new subclass of IAE. Thoughts? I think it is a bit overkill for this simple fix. We may discuss it as a part of some wider code cleanups. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15511#discussion_r1316081838 From duke at openjdk.org Tue Sep 5 15:46:17 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 15:46:17 GMT Subject: RFR: 8315585: Optimization for decimal to string [v3] In-Reply-To: References: Message-ID: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request with a new target base 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 optimization_for_decimal_to_string - BigInteger use a separate jla - update copyright info - optimization for decimal to string ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/97e4f7db..9743f6c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=01-02 Stats: 5698 lines in 156 files changed: 4437 ins; 811 del; 450 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From duke at openjdk.org Tue Sep 5 15:48:21 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Tue, 5 Sep 2023 15:48:21 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v11] In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: > [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.util.UUIDBench.toString" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) > > > > ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) > * cpu : aliyun yitian 710 (aarch64) > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) > > > ## 4. MacBookPro M1 Pro > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) > > > ## 5. Orange Pi 5 Plus > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us > > +Benchmark (size) Mode Cnt Score Error Units (PR) > +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) ??? has updated the pull request with a new target base 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 optimization_for_uuid_to_string - remove redundant parentheses - fix java doc, big-endian -> little-endian - Merge branch 'master' into optimization_for_uuid_to_string - use ByteArrayLittleEndian - fix typo - code style - Explain the rationale Co-authored-by: liach - private static final Unsafe - revert to the previous version - ... and 4 more: https://git.openjdk.org/jdk/compare/5e571f24...2d36332b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14745/files - new: https://git.openjdk.org/jdk/pull/14745/files/3f6d35df..2d36332b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=09-10 Stats: 5698 lines in 156 files changed: 4437 ins; 811 del; 450 mod Patch: https://git.openjdk.org/jdk/pull/14745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14745/head:pull/14745 PR: https://git.openjdk.org/jdk/pull/14745 From duke at openjdk.org Tue Sep 5 16:05:14 2023 From: duke at openjdk.org (Qing Xiao) Date: Tue, 5 Sep 2023 16:05:14 GMT Subject: RFR: 8315444: Convert test/jdk/tools to Classfile API [v2] In-Reply-To: References: Message-ID: > /test/jdk/tools/lib/tests/JImageValidator.java, tests in /test/jdk/tools/jlink and /test/jdk/tools/jimage use on com.sun.tools.classfile and should be converted to Classfile API. Qing Xiao has updated the pull request incrementally with one additional commit since the last revision: migrate test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java use Classfile API ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15529/files - new: https://git.openjdk.org/jdk/pull/15529/files/c658c8f1..48b6401c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15529&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15529&range=00-01 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15529/head:pull/15529 PR: https://git.openjdk.org/jdk/pull/15529 From brian.burkhalter at oracle.com Tue Sep 5 16:24:14 2023 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 5 Sep 2023 16:24:14 +0000 Subject: RFR: 8298619: java/io/File/GetXSpace.java is failing [v4] In-Reply-To: References: <6LnAAIclo5mZZgba4XUSTSc72vyNrBinzUlO9-kJXbU=.fe0c5e94-9e36-4484-b8e7-0f19cb10cb05@github.com> Message-ID: <9F77DB0B-0AE5-401F-8243-8075A03946EC@oracle.com> The changes to this test were developed on a native Windows 11 machine. I have never seen this problem. A web search suggests that this is a Windows error message possibly due to drive error. On Sep 4, 2023, at 5:16 AM, Andrey Turbanov > wrote: It seems after refactoring test started to fail on my Win11 VM. [?] java.lang.RuntimeException: The parameter is incorrect at GetXSpace.getSpace0(Native Method) at GetXSpace$Space.(GetXSpace.java:112) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sspitsyn at openjdk.org Tue Sep 5 16:58:40 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 5 Sep 2023 16:58:40 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v2] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 08:24:19 GMT, Alan Bateman wrote: >> In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM. >> >> The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition. >> >> Testing: tier1-5 > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Check for transition during stack walk for synchronous case > - Merge > - Initial commit Sorry for latency. I hope to finish my review today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15492#issuecomment-1706977299 From rriggs at openjdk.org Tue Sep 5 17:30:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Sep 2023 17:30:43 GMT Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v7] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 20:34:01 GMT, Vladimir Petko wrote: >> 8314491: Linux: jexec launched via PATH fails to find java > > Vladimir Petko has updated the pull request with a new target base 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 8314491-jexec-resolve-symlink > - Merge branch 'master' into 8314491-jexec-resolve-symlink > - declare error in-place > - remove unused imports > - Review comment: use /proc/self/exe as the backup option > - Merge branch 'master' into 8314491-jexec-resolve-symlink > - correct copyright statement > - Use /proc/self/exec to identify path to the executable. > - Create failing test for jexec in PATH issue LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15343#pullrequestreview-1611593920 From bchristi at openjdk.org Tue Sep 5 17:50:52 2023 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 5 Sep 2023 17:50:52 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v9] In-Reply-To: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> References: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> Message-ID: On Thu, 31 Aug 2023 17:09:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Merge > - Remove the new getInstance method taking varargs > - update mode to be int rather than long > - update tests > - Review feedback on javadoc > - Revised the API change. Add Option::DROP_METHOD_INFO > - Review feedback from Remi > - fixup javadoc > - Review feedback: move JLIA to ClassFrameInfo > - review feedback and javadoc clean up > - ... and 19 more: https://git.openjdk.org/jdk/compare/c8acab1d...111661bc Looks good. I like `DROP_METHOD_INFO`. I have just a few minor comments. src/java.base/share/classes/java/lang/StackStreamFactory.java line 657: > 655: static final class ClassFrameBuffer extends FrameBuffer { > 656: final StackWalker walker; > 657: ClassFrameInfo[] classFrames; // caller class for fast path Maybe I missed it, but I don't see any differences between `ClassFramesBuffer` and `StackFrameBuffer` other than the `ClassFrameInfo`/`StackFrameInfo` types. Could a single, generified Buffer class serve for both? test/micro/org/openjdk/bench/java/lang/StackWalkBench.java line 64: > 62: default -> throw new IllegalArgumentException(name); > 63: }; > 64: } The previous `WALKER_DEFAULT` would not have retained the Class reference, but the new `default` will? test/micro/org/openjdk/bench/java/lang/StackWalkBench.java line 360: > 358: } > 359: } > 360: I'm fine having this benchmark active by default, though offline we had discussed adding it commented out. ------------- PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1603548954 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1312375997 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1316143011 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1316205105 From bchristi at openjdk.org Tue Sep 5 17:50:57 2023 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 5 Sep 2023 17:50:57 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8] In-Reply-To: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> References: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> Message-ID: On Tue, 29 Aug 2023 20:51:56 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: > > - update mode to be int rather than long > - update tests > - Review feedback on javadoc src/java.base/share/classes/java/lang/ClassFrameInfo.java line 31: > 29: import java.lang.StackWalker.StackFrame; > 30: > 31: class ClassFrameInfo implements StackFrame { Maybe a minimal comment on when/how this class is used? src/java.base/share/classes/java/lang/ClassFrameInfo.java line 37: > 35: int flags; // updated by VM to set hidden and caller-sensitive bits > 36: > 37: ClassFrameInfo(StackWalker walker) { The StackFrameInfo constructor has comment. Maybe add one here, too? src/java.base/share/classes/java/lang/StackFrameInfo.java line 32: > 30: import java.lang.reflect.Modifier; > 31: > 32: class StackFrameInfo extends ClassFrameInfo { Maybe a minimal comment on when/how this class is used? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1310866414 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1310876832 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1310866565 From rriggs at openjdk.org Tue Sep 5 17:52:38 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Sep 2023 17:52:38 GMT Subject: RFR: 8315579: SPARC64 builds are broken after JDK-8304913 In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 07:28:03 GMT, Aleksey Shipilev wrote: > Similar to other issues in the same area. I have no SPARC machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the SPARC Zero build completes fine. Looks good, thanks for the cleanup. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15557#pullrequestreview-1611628260 From mchung at openjdk.org Tue Sep 5 17:57:48 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 5 Sep 2023 17:57:48 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v9] In-Reply-To: References: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> Message-ID: On Tue, 5 Sep 2023 16:44:24 GMT, Brent Christian wrote: >> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: >> >> - Merge >> - Remove the new getInstance method taking varargs >> - update mode to be int rather than long >> - update tests >> - Review feedback on javadoc >> - Revised the API change. Add Option::DROP_METHOD_INFO >> - Review feedback from Remi >> - fixup javadoc >> - Review feedback: move JLIA to ClassFrameInfo >> - review feedback and javadoc clean up >> - ... and 19 more: https://git.openjdk.org/jdk/compare/c8acab1d...111661bc > > test/micro/org/openjdk/bench/java/lang/StackWalkBench.java line 64: > >> 62: default -> throw new IllegalArgumentException(name); >> 63: }; >> 64: } > > The previous `WALKER_DEFAULT` would not have retained the Class reference, but the new `default` will? Some benchmarks need the Class reference but some do not. For simplicity, use only walkers that retain Class reference so that all benchmarks can run with the default walker. > test/micro/org/openjdk/bench/java/lang/StackWalkBench.java line 360: > >> 358: } >> 359: } >> 360: > > I'm fine having this benchmark active by default, though offline we had discussed adding it commented out. Having a second thought, I keep this active as that would be a good reference number for other benchmarks as they all build test stack. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1316213522 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1316215312 From naoto at openjdk.org Tue Sep 5 18:03:41 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Sep 2023 18:03:41 GMT Subject: RFR: 8315410: Undocumented exceptions in java.text.StringCharacterIterator In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 23:12:28 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315558) which is a conformance change to document some exceptions in the specification of java.text.StringCharacterIterator. src/java.base/share/classes/java/text/StringCharacterIterator.java line 158: > 156: * Implements CharacterIterator.setIndex() for String. > 157: * > 158: * @throws IllegalArgumentException if {@code p} is an invalid index It'd be clearer if we clarify what the `invalid` means ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15547#discussion_r1316222951 From mcimadamore at openjdk.org Tue Sep 5 18:05:47 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 5 Sep 2023 18:05:47 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v7] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 21:17:06 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Add comments. Simplify condition. Looks great - thanks! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15417#pullrequestreview-1611652306 From mcimadamore at openjdk.org Tue Sep 5 18:05:47 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 5 Sep 2023 18:05:47 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com> Message-ID: On Mon, 4 Sep 2023 14:30:06 GMT, Maurizio Cimadamore wrote: >> @TheRealMDoerr We've been discussing the shifts in order to wrap our heads around it, and we've ended up with this diagram in order to try and visualize what happens: >> >> Let's say we have a struct with 3 ints: >> >> >> struct Foo { >> int x; >> int y; >> int z; >> }; >> >> >> If this struct is passed as an argument, then the load of the second 'half' of the struct would look like this: >> >> >> offset : 0 .... 32 ..... 64 ..... 96 .... 128 >> values : xxxxxxxx|yyyyyyyy|zzzzzzzz|???????? (can't touch bits 96..128) >> Load int : V +--------+ >> | | >> +--------+ | >> V V >> In register : ????????|zzzzzzzz (MSBs are 0) >> Shift left : zzzzzzzz|00000000 (LSBs are zero) >> Write long : V V >> Result : xxxxxxxx|yyyyyyyy|zzzzzzzz|00000000 >> >> >> So, the 'Result' is padded at the tail with zeros. >> >> Does that seem right? Does it seem useful to add this diagram as a comment somewhere, for us when we come back to this code a year from now? Thanks > >> If this struct is passed as an argument, then the load of the second 'half' of the struct would look like this: > > It would perhaps be cleaner if in the MSB/LSB comments we said: > > LSBs are zzz...z > LSBs are 000...0 > > (e.g. avoid to refer to MSBs in the first, since those bytes are not exactly zero, they are the padding bytes) > @mcimadamore: May I ask you or somebody else from the Panama team to provide a 2nd review? This PR requires Panama knowledge, not really PPC knowledge. Sorry - I have already reviewed it - but didn't approve as I was waiting for @JornVernee to chime in. Now he has, and I will add my approval as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1707067130 From rriggs at openjdk.org Tue Sep 5 18:08:39 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Sep 2023 18:08:39 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com> References: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com> Message-ID: On Mon, 4 Sep 2023 11:01:23 GMT, Leo Korinth wrote: > 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1707072375 From redestad at openjdk.org Tue Sep 5 18:16:42 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 5 Sep 2023 18:16:42 GMT Subject: RFR: 8315585: Optimization for decimal to string [v3] In-Reply-To: References: Message-ID: <2pQ9OIOOwTXR7JKEDSNx8kC_7bVrgwoCoZPNcIAiuzk=.c3ffc4cc-7470-4b2a-900b-8a0a17de5955@github.com> On Tue, 5 Sep 2023 15:46:17 GMT, ??? wrote: >> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. >> >> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. >> >> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. >> >> The performance data is as follows: >> >> ## 1. benchmark script >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.math.BigDecimals.*ToPlainString" >> make test TEST="micro:java.math.BigDecimals.*ToEngineering" >> >> >> ## 2. benchmark environment >> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) >> * cpu intel xeon sapphire rapids (x64) >> >> ## 3. benchmark result >> >> -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) >> -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op >> -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op >> -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) >> +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) >> +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) >> +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op >> -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op >> -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op >> -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) >> +BigDecimals.testLargeToEngineeringStr... > > ??? has updated the pull request with a new target base 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 optimization_for_decimal_to_string > - BigInteger use a separate jla > - update copyright info > - optimization for decimal to string I think there is way too much duplication of logic going on here, primarily with `StringLatin1.getChars(long, int, byte[])` (assuming #14699 is accepted in the current state where `Integer.getChars(int, int, byte[])` and `Long.getChars(...)` is moved there). Perhaps the bulk of this could be moved to `StringLatin1` and then exposed via e.g. `JavaLangAccess`. On the motivation side I think it'd be helpful if you could point to some larger benchmarks, frameworks et.c. where optimizing `BigDecimal::toString` makes a significant difference. There has been some recent optimizations that remove the need for `BigDecimal::toString` for some code paths, e.g., #9410 - does this alleviate the need for this optimization or is this still useful or even critical? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1707087366 From joehw at openjdk.org Tue Sep 5 18:17:38 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 5 Sep 2023 18:17:38 GMT Subject: RFR: 8306632: Add a JDK Property for specifying DTD support In-Reply-To: References: Message-ID: On Sat, 2 Sep 2023 09:20:22 GMT, Alan Bateman wrote: > I think you've got this to a good place and brings uniformity to configuring how all the processors deal with DTDs. The proposal in the CSR is approved now so hopefully you'll get Reviewer cycles to help move forward on this. Thanks Alan! And with that, you voided Git bot's warning (inactive for more than 4 weeks, blah) :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15075#issuecomment-1707089292 From jlu at openjdk.org Tue Sep 5 19:07:51 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 5 Sep 2023 19:07:51 GMT Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for j.text.Format classes [v3] In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 22:26:00 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`). > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > instanceof should not be camel case CSR has been filed -> https://bugs.openjdk.org/browse/JDK-8315720 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15459#issuecomment-1707168054 From jlu at openjdk.org Tue Sep 5 19:09:23 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 5 Sep 2023 19:09:23 GMT Subject: RFR: 8315410: Undocumented exceptions in java.text.StringCharacterIterator [v2] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315558) which is a conformance change to document some exceptions in the specification of java.text.StringCharacterIterator. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Review: improve throws for setIndex ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15547/files - new: https://git.openjdk.org/jdk/pull/15547/files/a0582fdc..58c3f396 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15547&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15547&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15547/head:pull/15547 PR: https://git.openjdk.org/jdk/pull/15547 From lancea at openjdk.org Tue Sep 5 19:31:37 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Sep 2023 19:31:37 GMT Subject: RFR: 8306632: Add a JDK Property for specifying DTD support In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 18:41:48 GMT, Joe Wang wrote: > Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to specify how DTDs are handled. This property is uniformly supported across the JDK XML libraries. It complements, rather than replaces, the existing properties that are supportDTD for StAX and disallow-doctype-decl for DOM and SAX processors, which means the later will continue to work as they were and that if they are set, the new property will have no effect. Applications that use the existing properties continue to work as expected. > > This patch continues the path made previously with Xalan and XPath in which functions were moved into the jdk/xml classes. Similar changes are now made with the Xerces and XML classes, consolidating functions into the jdk/xml classes, reducing duplicate code for easier future maintenance. > > Tests: new tests are added to cover the various processors. > Existing tests pass. Only one was updated due to the change to the property impl. Hi Joe, I have made a few passes through the code and overall I think it is OK. Nothing jumped out and was glaringly wrong given you have touched a large number of classes and added a fair amount of additional tests ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15075#pullrequestreview-1611789294 From mdoerr at openjdk.org Tue Sep 5 19:50:40 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 5 Sep 2023 19:50:40 GMT Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API [v7] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 21:17:06 GMT, Martin Doerr wrote: >> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. >> >> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 88 88 0 0 >> >> >> Note: This PR should be considered as preparation work for AIX which also uses ABIv1. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Add comments. Simplify condition. Thanks for your outstanding support! I'm planning to integrate tomorrow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1707218477 From naoto at openjdk.org Tue Sep 5 19:53:44 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Sep 2023 19:53:44 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Sun, 3 Sep 2023 05:05:49 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing unnecessary commas > > src/java.base/share/classes/java/text/ListFormat.java line 46: > >> 44: * defined in Unicode Consortium's LDML specification for >> 45: * >> 46: * List Patterns. > > The main function, it seems to me, is to change the representation from one form to another. what would you think about the following: > > The {@code ListFormat} class is a tool for converting a list of strings to a text representation and vice versa in a locale-sensitive way. It transforms strings to text in accordance with the List Patterns (link) as defined in Unicode Consortium's LDML specification. For example, it can be used to format a list of 3 weekdays, i.e. "Monday", "Wednesday", "Friday", as "Monday, Wednesday, and Friday" in an inclusive list pattern. Thanks. Will modify the wording in the next revision. I think we should stick to the wording `format`/`parse` here. > src/java.base/share/classes/java/text/ListFormat.java line 48: > >> 46: * List Patterns. >> 47: *

>> 48: * Three types of concatenation are provided: {@link Type#STANDARD STANDARD}, > > A "Type" and "Style" together make up a specific pattern. It might be good to introduce the term "List Patterns" here first, that is, moving the introduction of patterns to the class description from the 1-arg getInstance method. once we have the terms established, we can then delve into the specific cases "types" and "styles" represent. Something like: > >

List Patterns

> List Patterns are rules that define how a series or list is formed ... (include the description for the getInstance(String[] patterns) here) > >

Standard Patterns

> {@code ListFormat} supports a few pre-defined patterns with a combination of Type (link) and Style(link). Types and Styles are defined as follows. > >

Type

> {@link Type#STANDARD STANDARD}: a simple list with conjunction "and"; > > ... > >

Style

> {@link Style#FULL FULL}: uses the conjunction word such as "and"; > > {@link Style#SHORT SHORT}: uses the shorthand of the conjunction word, "&" (ampersand) for "and" for example; > > {@link Style#NARROW NARROW}: uses no conjunction word. > > For example, a combination of {@link Type#STANDARD STANDARD} and {@link Style#FULL FULL} forms an inclusive list pattern. I think that Type/Style/Locale forming a specific pattern is an implementation detail, so I would not describe it in the spec (although as you say they form a specific pattern in the impl). It could be that an impl of 3-arg getInstance() can be independent of patterns described in 1-arg getInstance(). > src/java.base/share/classes/java/text/ListFormat.java line 521: > >> 519: var sb = new StringBuilder(256).append(patterns[START]); >> 520: IntStream.range(2, count - 1).forEach(i -> sb.append(middleBetween).append("{").append(i).append("}")); >> 521: sb.append(patterns[END].replaceFirst("\\{0}", "").replaceFirst("\\{1}", "\\{" + (count - 1) + "\\}")); > > From what it looks, it could be a concern for potentially adding large number of long strings with a list of small items. I don't seem to see where the input is limited. Good point. Will add some kind of limitation. > src/java.base/share/classes/java/text/ListFormat.java line 560: > >> 558: * The {@code UNIT} ListFormat style. This style concatenates >> 559: * elements, useful for enumerating units. >> 560: */ > > The word "style" used in Type, I assume you meant "type"? Just that it might be confused with Style below. > > Same as previous comments, a combination of Type and Style, if I understand correctly, forms a specific pattern. I might say something about it in the enum class description. > > A STANDARD type then is a simple list with conjunction "and", or an inclusive list, and etc. Ah, good catch. Will correct those style/type typos. > A STANDARD type then is a simple list with conjunction "and", or an inclusive list, and etc. I could not quite catch what you meant by this. Can you please elaborate on it more? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316330290 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316330343 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316330443 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316330402 From rriggs at openjdk.org Tue Sep 5 20:07:44 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Sep 2023 20:07:44 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 19:50:20 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/ListFormat.java line 46: >> >>> 44: * defined in Unicode Consortium's LDML specification for >>> 45: * >>> 46: * List Patterns. >> >> The main function, it seems to me, is to change the representation from one form to another. what would you think about the following: >> >> The {@code ListFormat} class is a tool for converting a list of strings to a text representation and vice versa in a locale-sensitive way. It transforms strings to text in accordance with the List Patterns (link) as defined in Unicode Consortium's LDML specification. For example, it can be used to format a list of 3 weekdays, i.e. "Monday", "Wednesday", "Friday", as "Monday, Wednesday, and Friday" in an inclusive list pattern. > > Thanks. Will modify the wording in the next revision. I think we should stick to the wording `format`/`parse` here. I'd stick to the general first sentence structure used by DateFormat, Format, and MessageFormat. ("tools" in OpenJDK are standalone programs.) For example, "ListFormat formats and parses lists of strings." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316343327 From dl at openjdk.org Tue Sep 5 20:16:26 2023 From: dl at openjdk.org (Doug Lea) Date: Tue, 5 Sep 2023 20:16:26 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v24] 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: Avoid needing test threads ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14301/files - new: https://git.openjdk.org/jdk/pull/14301/files/551a9cf8..787c1cb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=22-23 Stats: 208 lines in 1 file changed: 20 ins; 65 del; 123 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 Tue Sep 5 20:19:41 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Sep 2023 20:19:41 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 20:04:57 GMT, Roger Riggs wrote: >> Thanks. Will modify the wording in the next revision. I think we should stick to the wording `format`/`parse` here. > > I'd stick to the general first sentence structure used by DateFormat, Format, and MessageFormat. > ("tools" in OpenJDK are standalone programs.) > > For example, > "ListFormat formats and parses lists of strings." I agree, Roger. The current version is derived from MessageFormat, which is the closest of all the *Format classes. Will come up with a better one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316364083 From rriggs at openjdk.org Tue Sep 5 20:19:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Sep 2023 20:19:43 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 19:50:23 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/ListFormat.java line 48: >> >>> 46: * List Patterns. >>> 47: *

>>> 48: * Three types of concatenation are provided: {@link Type#STANDARD STANDARD}, >> >> A "Type" and "Style" together make up a specific pattern. It might be good to introduce the term "List Patterns" here first, that is, moving the introduction of patterns to the class description from the 1-arg getInstance method. once we have the terms established, we can then delve into the specific cases "types" and "styles" represent. Something like: >> >>

List Patterns

>> List Patterns are rules that define how a series or list is formed ... (include the description for the getInstance(String[] patterns) here) >> >>

Standard Patterns

>> {@code ListFormat} supports a few pre-defined patterns with a combination of Type (link) and Style(link). Types and Styles are defined as follows. >> >>

Type

>> {@link Type#STANDARD STANDARD}: a simple list with conjunction "and"; >> >> ... >> >>

Style

>> {@link Style#FULL FULL}: uses the conjunction word such as "and"; >> >> {@link Style#SHORT SHORT}: uses the shorthand of the conjunction word, "&" (ampersand) for "and" for example; >> >> {@link Style#NARROW NARROW}: uses no conjunction word. >> >> For example, a combination of {@link Type#STANDARD STANDARD} and {@link Style#FULL FULL} forms an inclusive list pattern. > > I think that Type/Style/Locale forming a specific pattern is an implementation detail, so I would not describe it in the spec (although as you say they form a specific pattern in the impl). It could be that an impl of 3-arg getInstance() can be independent of patterns described in 1-arg getInstance(). Type and Style select a pattern defined for the locale. (for the zero arg and three arg getInstance methods). I think I would avoid the term "concatenation", the type defines a pattern that contains punctuation and connecting words. The style selects among the full, short, and narrow patterns. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316362486 From joehw at openjdk.org Tue Sep 5 20:24:41 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 5 Sep 2023 20:24:41 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: <8GOBPyqxlS_iRLOl0dbiDbUwhBdPLmIgdhbCFOT_u-Q=.0c35bc3a-080e-4fcd-9a1e-9c78cf30c1ee@github.com> On Tue, 5 Sep 2023 20:17:14 GMT, Naoto Sato wrote: >> I'd stick to the general first sentence structure used by DateFormat, Format, and MessageFormat. >> ("tools" in OpenJDK are standalone programs.) >> >> For example, >> "ListFormat formats and parses lists of strings." > > I agree, Roger. The current version is derived from MessageFormat, which is the closest of all the *Format classes. Will come up with a better one. Sounds good. I mainly want to say that ListFormat doesn't create (produce) new items but change (convert) the presentation from one form to another. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316367777 From rriggs at openjdk.org Tue Sep 5 20:28:42 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Sep 2023 20:28:42 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 19:50:29 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/ListFormat.java line 521: >> >>> 519: var sb = new StringBuilder(256).append(patterns[START]); >>> 520: IntStream.range(2, count - 1).forEach(i -> sb.append(middleBetween).append("{").append(i).append("}")); >>> 521: sb.append(patterns[END].replaceFirst("\\{0}", "").replaceFirst("\\{1}", "\\{" + (count - 1) + "\\}")); >> >> From what it looks, it could be a concern for potentially adding large number of long strings with a list of small items. I don't seem to see where the input is limited. > > Good point. Will add some kind of limitation. I can't see what arbitrary limit would make sense. But perhaps an APINote that formatting the string from an excessively long list may exceed memory or string sizes. (Without being specific about the exception being thrown). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316371355 From joehw at openjdk.org Tue Sep 5 20:32:42 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 5 Sep 2023 20:32:42 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 20:15:26 GMT, Roger Riggs wrote: >> I think that Type/Style/Locale forming a specific pattern is an implementation detail, so I would not describe it in the spec (although as you say they form a specific pattern in the impl). It could be that an impl of 3-arg getInstance() can be independent of patterns described in 1-arg getInstance(). > > Type and Style select a pattern defined for the locale. (for the zero arg and three arg getInstance methods). > I think I would avoid the term "concatenation", the type defines a pattern that contains punctuation and connecting words. The style selects among the full, short, and narrow patterns. I thought they're already a part of the public API described in the current javadoc, e.g. ListFormat.Style and ListFormat.Type (https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html). I thought you meant to support general patterns (the List Patterns) and a few (specific) "type attributes" as in the LDML spec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316375403 From naoto at openjdk.org Tue Sep 5 20:48:54 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Sep 2023 20:48:54 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 20:29:53 GMT, Joe Wang wrote: >> Type and Style select a pattern defined for the locale. (for the zero arg and three arg getInstance methods). >> I think I would avoid the term "concatenation", the type defines a pattern that contains punctuation and connecting words. The style selects among the full, short, and narrow patterns. > > I thought they're already a part of the public API described in the current javadoc, e.g. ListFormat.Style and ListFormat.Type (https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html). I thought you meant to support general patterns (the List Patterns) and a few (specific) "type attributes" as in the LDML spec. Yes, they are public API. My intention was to keep those patterns exposure as minimal as possible, as they are complicated so that users who just wish to acquire formats only with Type/Style/Locale need not know it. Only those who want to customize their own patterns can do so with the 1-arg getInstance(), thus I wanted the description in that method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316388330 From naoto at openjdk.org Tue Sep 5 20:48:56 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Sep 2023 20:48:56 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 20:25:52 GMT, Roger Riggs wrote: >> Good point. Will add some kind of limitation. > > I can't see what arbitrary limit would make sense. > But perhaps an APINote that formatting the string from an excessively long list may exceed memory or string sizes. (Without being specific about the exception being thrown). OK, will add that @apiNote in the 1-arg getInstance() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316389440 From asemenyuk at openjdk.org Tue Sep 5 20:52:38 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 5 Sep 2023 20:52:38 GMT Subject: RFR: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 In-Reply-To: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> References: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> Message-ID: On Fri, 1 Sep 2023 07:22:12 GMT, Matthias Baesken wrote: > on some RHEL Linux 8.X machines , we run into errors in test tools/jpackage/share/RuntimePackageTest.java#id0 , error can be seen below. > It looks like these errors occur when running the jtreg tests with higher concurrency, I did not see them when running just the single test. > > When adding some test output , we see the 2 top install dirs below (1 is expected, not 2) : > ./test/unpacked-rpm/opt > ./test/unpacked-rpm/usr > > error output : > > java.lang.AssertionError: Expected [1]. Actual [2]: Check the package has 1 top installation directories > at jdk.jpackage.test.TKit.error(TKit.java:273) > at jdk.jpackage.test.TKit.assertEquals(TKit.java:576) > at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:705) > at jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$3(PackageTest.java:635) > at java.base/java.util.Optional.ifPresent(Optional.java:178) > at jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:633) > at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:592) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) > at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) > at java.base/java.lang.Iterable.forEach(Iterable.java:75) > at jdk.jpackage.test.PackageTest.lambda$runActions$24(PackageTest.java:381) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.lambda$runActions$25(PackageTest.java:380) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.runActions(PackageTest.java:379) > at jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) > at RuntimePackageTest.test(RuntimePackageTest.java:83) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) > at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) > at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) > at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708) > at java.base/jav... Changes requested by asemenyuk (Reviewer). test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 708: > 706: var files2 = Files.list(unpackedDir); > 707: files2.forEach(System.out::println); > 708: Please remove this debug output. It will clutter normal test output when it successfully passes the following `TKit.assertEquals` check. ------------- PR Review: https://git.openjdk.org/jdk/pull/15528#pullrequestreview-1607198630 PR Review Comment: https://git.openjdk.org/jdk/pull/15528#discussion_r1313194858 From joehw at openjdk.org Tue Sep 5 21:02:41 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 5 Sep 2023 21:02:41 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 19:50:26 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/ListFormat.java line 560: >> >>> 558: * The {@code UNIT} ListFormat style. This style concatenates >>> 559: * elements, useful for enumerating units. >>> 560: */ >> >> The word "style" used in Type, I assume you meant "type"? Just that it might be confused with Style below. >> >> Same as previous comments, a combination of Type and Style, if I understand correctly, forms a specific pattern. I might say something about it in the enum class description. >> >> A STANDARD type then is a simple list with conjunction "and", or an inclusive list, and etc. > > Ah, good catch. Will correct those style/type typos. > >> A STANDARD type then is a simple list with conjunction "and", or an inclusive list, and etc. > > I could not quite catch what you meant by this. Can you please elaborate on it more? In a List Pattern, Type, as in the current document, defined its type as in the language, while Style the writing style. I guess I would try to avoid stating it "concatenates elements", but rather represents a simple list with conjunction "and", that is also called an inclusive list as in the language term. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316401513 From rriggs at openjdk.org Tue Sep 5 21:17:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Sep 2023 21:17:43 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 16:51:49 GMT, Naoto Sato wrote: >> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removing unnecessary commas src/java.base/share/classes/java/text/ListFormat.java line 59: > 57: * } > 58: * This will produce the concatenated list string, "Foo, Bar, and Baz" as seen in > 59: * the following table: Suggestion: * the following: src/java.base/share/classes/java/text/ListFormat.java line 84: > 82: * > 83: * Note that the above chart represents the examples in the CLDR definition, > 84: * and there could be different patterns from other locale providers. Suggestion: * Note: these examples are from CLDR, there could be different patterns from other locale providers. src/java.base/share/classes/java/text/ListFormat.java line 90: > 88: * method specifies the delimiting patterns for the start/middle/end portion of > 89: * the formatted string, as well as optional specialized patterns for two or three > 90: * elements. Refer to the method description for more detail. Suggestion: * Alternatively, more flexible patterns can be constructed from the pattern parts for the start, middle, * and end of the formatted list as well as specialized patterns for lists of two or three elements. * Refer to the {@link #getInstance(String[])} method description for more detail. src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java line 840: > 838: * > 839: * @param type type. one of {@link ListFormat.Type} > 840: * @param style Style. one of {@link ListFormat.Style} Suggestion: * @param type a {@link ListFormat.Type} * @param style a {@link ListFormat.Style} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316403770 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316405139 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316412400 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316400394 From psandoz at openjdk.org Tue Sep 5 22:03:49 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 5 Sep 2023 22:03:49 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v10] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 15:54:41 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 five additional commits since the last revision: > > - 8315096: Allowed access modes in memory segment should depend on layout alignment > > Reviewed-by: psandoz > - Add missing @implSpec to AddressLayout > > Reviewed-by: pminborg > - Fix misc typos in FFM API javadoc > > Reviewed-by: jvernee > - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two) > > Reviewed-by: pminborg > - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle > > Reviewed-by: jvernee Recommend you do a sweep through the code for unused imports and fields and any rogue `@since` in the internal classes. src/java.base/share/classes/java/lang/foreign/AddressLayout.java line 53: > 51: * > 52: * @implSpec > 53: * This class is immutable, thread-safe and value-based. Strictly speaking it's the implementations, as stated in the `Linker`: * Implementations of this interface are immutable, thread-safe and value-based. src/java.base/share/classes/java/lang/foreign/Linker.java line 152: > 150: *

> 151: * The following table shows some examples of how C types are modelled in Linux/x64 (all the examples provided > 152: * here will assume these platform-dependent mappings): Up to you, but it might be useful to link to the ABI specifications if the links are considered stable. src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 439: > 437: * > 438: *

> 439: * If the provided layout path {@code P} contains no dereference elements, then the offset of the access operation is Suggestion: * If the provided layout path {@code P} contains no dereference elements, then the offset {@code O} of the access operation is src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 443: > 441: * > 442: * {@snippet lang = "java": > 443: * offset = this.offsetHandle(P).invokeExact(B, I1, I2, ... In); Suggestion: * O = this.offsetHandle(P).invokeExact(B, I1, I2, ... In); To align with the use of `O` later on. src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 536: > 534: * > 535: *

> 536: * The offset of the returned segment is computed as if by a call to a Suggestion: * The offset {@code O} of the returned segment is computed as if by a call to a src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 154: > 152: * MemoryLayout.sequenceLayout(4, ValueLayout.JAVA_INT).withName("data") // array of 4 elements > 153: * ); > 154: * VarHandle intHandle = segmentLayout.varHandle(MemoryLayout.PathElemenet.groupElement("data"), Suggestion: * VarHandle intHandle = segmentLayout.varHandle(MemoryLayout.PathElement.groupElement("data"), src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8027: > 8025: * @since 19 > 8026: */ > 8027: @PreviewFeature(feature=PreviewFeature.Feature.FOREIGN) Unused import to `PreviewFeature`, and possibly others too. src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 45: > 43: case DOUBLE_BYTE -> readFast_short(segment, offset, charset); > 44: case QUAD_BYTE -> readFast_int(segment, offset, charset); > 45: default -> throw new UnsupportedOperationException("Unsupported charset: " + charset); Is this necessary, since the switch expression should be exhaustive over all the enum values? ------------- PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1611924844 PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316401360 PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316402470 PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316409959 PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316410079 PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316414805 PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316437803 PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316457079 PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316444767 From phh at openjdk.org Tue Sep 5 22:15:39 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 5 Sep 2023 22:15:39 GMT Subject: RFR: 8315579: SPARC64 builds are broken after JDK-8304913 In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 07:28:03 GMT, Aleksey Shipilev wrote: > Similar to other issues in the same area. I have no SPARC machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the SPARC Zero build completes fine. GHA failure on linux-x86 tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java is an instance of a "Overflow during reference processing" crash. ------------- Marked as reviewed by phh (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15557#pullrequestreview-1612019960 From naoto at openjdk.org Tue Sep 5 22:19:39 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Sep 2023 22:19:39 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v13] In-Reply-To: References: Message-ID: > Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html Naoto Sato has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/java/text/ListFormat.java Co-authored-by: Roger Riggs - Update src/java.base/share/classes/java/text/ListFormat.java Co-authored-by: Roger Riggs - Update src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java Co-authored-by: Roger Riggs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15130/files - new: https://git.openjdk.org/jdk/pull/15130/files/a228a3e3..4022c9db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=11-12 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130 PR: https://git.openjdk.org/jdk/pull/15130 From naoto at openjdk.org Tue Sep 5 22:20:40 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Sep 2023 22:20:40 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v12] In-Reply-To: References: Message-ID: <90BFOarXj5A__J2h0MaJym7E9jUbVVem3hwqTlMRPOI=.94b02378-5ba6-48a8-991a-f2324863231f@github.com> On Tue, 5 Sep 2023 21:14:00 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing unnecessary commas > > src/java.base/share/classes/java/text/ListFormat.java line 90: > >> 88: * method specifies the delimiting patterns for the start/middle/end portion of >> 89: * the formatted string, as well as optional specialized patterns for two or three >> 90: * elements. Refer to the method description for more detail. > > Suggestion: > > * Alternatively, more flexible patterns can be constructed from the pattern parts for the start, middle, > * and end of the formatted list as well as specialized patterns for lists of two or three elements. > * Refer to the {@link #getInstance(String[])} method description for more detail. For this part, I would not use `patterns` in the first suggested sentence but use `more flexible ListFormat instances` instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1316476327 From msheppar at openjdk.org Tue Sep 5 22:25:39 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 5 Sep 2023 22:25:39 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 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 one additional commit since the last revision: > > fix static import > From talking to other HotSpot devs it is quite clear that the different names lead to mistakes when writing (copy-n-pasting) tests, so I'm happy that we try to figure out some way to make it more obvious when we prepend the extra test options and when we don't. > > I agree with @msheppar that `createTestJvm` isn't a good name and I wouldn't be opposed to changing that name instead of `createJavaProcessBuilder`. However, if we do rename that function I strongly urge us to also rename the corresponding `executeTestJvm` function. > > I also think it is too obscure that functions with _Test_ in the name prepend the extra test options, and those without _Test_ don't, so I'd like to get rid of that convention. > > I wouldn't be opposed to a change that: > > * Keeps the `createJavaProcessBuilder` name > > * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts` > > * Renames `executeTestJvm` to `executeJavaPrependTestOpts` > > * Removes `createTestJava` > > * Removes `executeTestJava` I think @stefank made a reasonable suggestion which was endorsed by @AlanBateman which would remove the misconception hurdle ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1707391042 From naoto at openjdk.org Tue Sep 5 22:47:01 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Sep 2023 22:47:01 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v14] In-Reply-To: References: Message-ID: > Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Incorporating suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15130/files - new: https://git.openjdk.org/jdk/pull/15130/files/4022c9db..316ed12d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=12-13 Stats: 20 lines in 1 file changed: 7 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/15130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130 PR: https://git.openjdk.org/jdk/pull/15130 From erikj at openjdk.org Tue Sep 5 22:58:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 5 Sep 2023 22:58:17 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header Message-ID: There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. ------------- Commit messages: - JDK-8267174 Changes: https://git.openjdk.org/jdk/pull/15573/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15573&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8267174 Stats: 1944 lines in 648 files changed: 0 ins; 1296 del; 648 mod Patch: https://git.openjdk.org/jdk/pull/15573.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15573/head:pull/15573 PR: https://git.openjdk.org/jdk/pull/15573 From cjplummer at openjdk.org Tue Sep 5 23:15:36 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 5 Sep 2023 23:15:36 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1707426607 From jjg at openjdk.org Tue Sep 5 23:18:39 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 5 Sep 2023 23:18:39 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. One has to wonder about the `**/*_OLD.java` files, but that would be a different cleanup ------------- PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1612069262 From naoto at openjdk.org Tue Sep 5 23:28:38 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Sep 2023 23:28:38 GMT Subject: RFR: 8315410: Undocumented exceptions in java.text.StringCharacterIterator [v2] In-Reply-To: References: Message-ID: <3aq9q6DeoE6lB52Mgjc31b37qwdjmHIHsyEAvTL50SM=.3e9cc079-105d-47db-ab09-292a3c209770@github.com> On Tue, 5 Sep 2023 19:09:23 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315558) which is a conformance change to document some exceptions in the specification of java.text.StringCharacterIterator. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Review: improve throws for setIndex LGTM. Reviewed the CSR too. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15547#pullrequestreview-1612083815 From valeriep at openjdk.org Tue Sep 5 23:37:37 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 5 Sep 2023 23:37:37 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. Security area looks good. ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1612089791 From liach at openjdk.org Tue Sep 5 23:38:41 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 5 Sep 2023 23:38:41 GMT Subject: RFR: 8315444: Convert test/jdk/tools to Classfile API [v2] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 16:05:14 GMT, Qing Xiao wrote: >> `/test/jdk/tools/lib/tests/JImageValidator.java`, tests in `/test/jdk/tools/jlink`, and `/test/jdk/tools/jimage`, `/test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java` use on com.sun.tools.classfile and should be converted to Classfile API. > > Qing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > migrate test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java use Classfile API In addition, I don't think we should open the `classfile.impl` package to tests; this package is not meant to be exported. test/jdk/tools/lib/tests/JImageValidator.java line 225: > 223: > 224: public static void readClass(byte[] clazz) throws IOException { > 225: Classfile.of().parse(clazz); Notice that the old API might throw different exceptions compared to the new one; the new one is lazy, e.g. if there's broken interface entry but the interfaces are not queried, no exception is thrown. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15529#issuecomment-1707443036 PR Review Comment: https://git.openjdk.org/jdk/pull/15529#discussion_r1316517689 From duke at openjdk.org Wed Sep 6 01:39:50 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 01:39:50 GMT Subject: RFR: 8315585: Optimization for decimal to string [v3] In-Reply-To: References: Message-ID: <6WEWo5_B3v7xRiTcWtjXotFiTuC1XUgD6gVBTX0rB5c=.245c644f-06f8-48ae-9bfa-0fcfad1f37fc@github.com> On Tue, 5 Sep 2023 15:46:17 GMT, ??? wrote: >> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. >> >> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. >> >> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. >> >> The performance data is as follows: >> >> ## 1. benchmark script >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.math.BigDecimals.*ToPlainString" >> make test TEST="micro:java.math.BigDecimals.*ToEngineering" >> >> >> ## 2. benchmark environment >> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) >> * cpu intel xeon sapphire rapids (x64) >> >> ## 3. benchmark result >> >> -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) >> -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op >> -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op >> -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) >> +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) >> +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) >> +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op >> -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op >> -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op >> -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) >> +BigDecimals.testLargeToEngineeringStr... > > ??? has updated the pull request with a new target base 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 optimization_for_decimal_to_string > - BigInteger use a separate jla > - update copyright info > - optimization for decimal to string Reducing code duplication with JavaLangAccess is a good suggestion, I'm waiting for #14699 to be merged. I am the author of the json library [fastjson](https://github.com/alibaba/fastjson) and [fastjson2](https://github.com/alibaba/fastjson2). When serializing BigDecimal type data to JSON, I found that BigDecimal has performance improvements. Including the following methods: * toString * toPlainString * new BigDecimal(String) These optimizations are not only useful for [fastjson](https://github.com/alibaba/fastjson) and [fastjson2](https://github.com/alibaba/fastjson2), but also for [gson](https://github.com/google/gson)/[jackson](https://github.com/FasterXML/jackson-databind) and many other libraries. The optimization of #9410 is doubleValue, which is not related to toString/toPlainString. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1707520521 From duke at openjdk.org Wed Sep 6 03:34:04 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 03:34:04 GMT Subject: RFR: 8315585: Optimization for decimal to string [v4] In-Reply-To: References: Message-ID: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into optimization_for_decimal_to_string - Merge branch 'master' into optimization_for_decimal_to_string - BigInteger use a separate jla - update copyright info - optimization for decimal to string ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/9743f6c1..d840e3fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=02-03 Stats: 1011 lines in 28 files changed: 812 ins; 155 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From darcy at openjdk.org Wed Sep 6 03:38:53 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 6 Sep 2023 03:38:53 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v9] In-Reply-To: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> References: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> Message-ID: <1HM2JHqDos0Iff0GDfZHZRFfNbnHu_Ltj6za0pmu4h0=.702c4109-c918-4291-a253-c78e208487f2@github.com> On Thu, 31 Aug 2023 17:09:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Merge > - Remove the new getInstance method taking varargs > - update mode to be int rather than long > - update tests > - Review feedback on javadoc > - Revised the API change. Add Option::DROP_METHOD_INFO > - Review feedback from Remi > - fixup javadoc > - Review feedback: move JLIA to ClassFrameInfo > - review feedback and javadoc clean up > - ... and 19 more: https://git.openjdk.org/jdk/compare/c8acab1d...111661bc src/java.base/share/classes/java/lang/StackWalker.java line 114: > 112: public interface StackFrame { > 113: /** > 114: * {@return the binary name I think `binary name` can now be replaced with `{@linkplain ClassLoader##binary-name binary name}`. HTH ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1316675662 From darcy at openjdk.org Wed Sep 6 04:20:37 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 6 Sep 2023 04:20:37 GMT Subject: RFR: 8315585: Optimization for decimal to string [v4] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 03:34:04 GMT, ??? wrote: >> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. >> >> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. >> >> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. >> >> The performance data is as follows: >> >> ## 1. benchmark script >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.math.BigDecimals.*ToPlainString" >> make test TEST="micro:java.math.BigDecimals.*ToEngineering" >> >> >> ## 2. benchmark environment >> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) >> * cpu intel xeon sapphire rapids (x64) >> >> ## 3. benchmark result >> >> -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) >> -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op >> -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op >> -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) >> +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) >> +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) >> +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op >> -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op >> -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op >> -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) >> +BigDecimals.testLargeToEngineeringStr... > > ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into optimization_for_decimal_to_string > - Merge branch 'master' into optimization_for_decimal_to_string > - BigInteger use a separate jla > - update copyright info > - optimization for decimal to string Besides a review of the performance changes, myself or someone else who works on BigInteger and BigDecimal will need to review the changes. >From a quick look, it may be appropriate to add addition test cases to explicitly exercise the new code paths. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1707631267 From sspitsyn at openjdk.org Wed Sep 6 05:04:49 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Sep 2023 05:04:49 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v2] In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 08:24:19 GMT, Alan Bateman wrote: >> In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM. >> >> The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition. >> >> Testing: tier1-5 > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Check for transition during stack walk for synchronous case > - Merge > - Initial commit The fix looks okay to me. From JVMTI point of view this transition is hidden, so no inconsistency can be observed. However, I wonder if the AsyncGetStackTraces may have similar issue as the JFR had. Unfortunately we do not have good test coverage to rely on. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15492#pullrequestreview-1612449636 From mbaesken at openjdk.org Wed Sep 6 07:29:20 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Sep 2023 07:29:20 GMT Subject: RFR: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 [v2] In-Reply-To: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> References: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> Message-ID: > on some RHEL Linux 8.X machines , we run into errors in test tools/jpackage/share/RuntimePackageTest.java#id0 , error can be seen below. > It looks like these errors occur when running the jtreg tests with higher concurrency, I did not see them when running just the single test. > > When adding some test output , we see the 2 top install dirs below (1 is expected, not 2) : > ./test/unpacked-rpm/opt > ./test/unpacked-rpm/usr > > error output : > > java.lang.AssertionError: Expected [1]. Actual [2]: Check the package has 1 top installation directories > at jdk.jpackage.test.TKit.error(TKit.java:273) > at jdk.jpackage.test.TKit.assertEquals(TKit.java:576) > at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:705) > at jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$3(PackageTest.java:635) > at java.base/java.util.Optional.ifPresent(Optional.java:178) > at jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:633) > at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:592) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) > at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) > at java.base/java.lang.Iterable.forEach(Iterable.java:75) > at jdk.jpackage.test.PackageTest.lambda$runActions$24(PackageTest.java:381) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.lambda$runActions$25(PackageTest.java:380) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.runActions(PackageTest.java:379) > at jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) > at RuntimePackageTest.test(RuntimePackageTest.java:83) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) > at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) > at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) > at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708) > at java.base/jav... Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: remove output from PackageTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15528/files - new: https://git.openjdk.org/jdk/pull/15528/files/b630eef0..976f4f91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15528&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15528&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15528/head:pull/15528 PR: https://git.openjdk.org/jdk/pull/15528 From mbaesken at openjdk.org Wed Sep 6 07:29:20 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Sep 2023 07:29:20 GMT Subject: RFR: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 [v2] In-Reply-To: References: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> Message-ID: On Fri, 1 Sep 2023 15:40:00 GMT, Alexey Semenyuk wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> remove output from PackageTest.java > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java line 708: > >> 706: var files2 = Files.list(unpackedDir); >> 707: files2.forEach(System.out::println); >> 708: > > Please remove this debug output. It will clutter normal test output when it successfully passes the following `TKit.assertEquals` check. Hi Alexey, I removed the output from the test . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15528#discussion_r1316847911 From alanb at openjdk.org Wed Sep 6 07:53:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Sep 2023 07:53:36 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote: > One has to wonder about the `**/*_OLD.java` files, but that would be a different cleanup The IBM double byte charsets were re-implemented in JDK 7. I think the old implementations moved to the test tree so it could be used to test the new/replacement implementations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1707845577 From duke at openjdk.org Wed Sep 6 08:26:00 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 6 Sep 2023 08:26:00 GMT Subject: RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX Message-ID: After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX : com/sun/tools/attach/warnings/DynamicLoadWarningTest.java; The problem was described in [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) with a first try of a fix. A second fix via [JDK-8310191](https://bugs.openjdk.org/browse/JDK-8310191) was necessary. Both fixes just disable the specific subtest on AIX, without correction of the root cause. The root cause is, that dlopen() on AIX returns different handles every time, even if you load a library twice. There is no official AIX API available to get this information on a different way. My proposal is, to use the stat64x API with the fields st_device and st_inode. After a dlopen() the stat64x() API is called additionally to get this information which is then stored parallel to the library handle in the jvmtiAgent. For AIX we then can compare these values instead of the library handle and get the same functionality as on linux. ------------- Commit messages: - JDK-8315706 Changes: https://git.openjdk.org/jdk/pull/15583/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15583&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315706 Stats: 121 lines in 5 files changed: 118 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15583.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15583/head:pull/15583 PR: https://git.openjdk.org/jdk/pull/15583 From mdoerr at openjdk.org Wed Sep 6 08:29:58 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 6 Sep 2023 08:29:58 GMT Subject: Integrated: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 13:56:12 GMT, Martin Doerr wrote: > I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code. > > Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/foreign 88 88 0 0 > > > Note: This PR should be considered as preparation work for AIX which also uses ABIv1. This pull request has now been integrated. Changeset: f6c203e6 Author: Martin Doerr URL: https://git.openjdk.org/jdk/commit/f6c203e61620dc130b8c366f824e6923fca52e82 Stats: 311 lines in 11 files changed: 295 ins; 8 del; 8 mod 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API Reviewed-by: mcimadamore, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/15417 From shade at openjdk.org Wed Sep 6 08:30:46 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Sep 2023 08:30:46 GMT Subject: RFR: 8315579: SPARC64 builds are broken after JDK-8304913 In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 07:28:03 GMT, Aleksey Shipilev wrote: > Similar to other issues in the same area. I have no SPARC machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the SPARC Zero build completes fine. Thanks for reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15557#issuecomment-1707895981 From shade at openjdk.org Wed Sep 6 08:30:47 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Sep 2023 08:30:47 GMT Subject: Integrated: 8315579: SPARC64 builds are broken after JDK-8304913 In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 07:28:03 GMT, Aleksey Shipilev wrote: > Similar to other issues in the same area. I have no SPARC machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the SPARC Zero build completes fine. This pull request has now been integrated. Changeset: cfc14893 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/cfc148930b6ace3e3ee298d7ac82aefbc652d447 Stats: 13 lines in 3 files changed: 12 ins; 0 del; 1 mod 8315579: SPARC64 builds are broken after JDK-8304913 Reviewed-by: rriggs, phh ------------- PR: https://git.openjdk.org/jdk/pull/15557 From alanb at openjdk.org Wed Sep 6 08:37:38 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Sep 2023 08:37:38 GMT Subject: RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 08:18:45 GMT, JoKern65 wrote: > After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX : > com/sun/tools/attach/warnings/DynamicLoadWarningTest.java; > The problem was described in [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) with a first try of a fix. > A second fix via [JDK-8310191](https://bugs.openjdk.org/browse/JDK-8310191) was necessary. > Both fixes just disable the specific subtest on AIX, without correction of the root cause. > The root cause is, that dlopen() on AIX returns different handles every time, even if you load a library twice. There is no official AIX API available to get this information on a different way. > My proposal is, to use the stat64x API with the fields st_device and st_inode. After a dlopen() the stat64x() API is called additionally to get this information which is then stored parallel to the library handle in the jvmtiAgent. For AIX we then can compare these values instead of the library handle and get the same functionality as on linux. Just to point out that AIX behavior is not wrong, the spec is clear that "it is implementation specific as to whether a warning is printed when attempting to start the same agent a second or subsequent time". Just pointing it out as you have the option to avoid this complexity if you want. The cited JBS issues are because the original tests for JEP 451 assumed that there would be additional warnings when the same agent was loaded/started several times. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15583#issuecomment-1707909744 From asotona at openjdk.org Wed Sep 6 09:11:45 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 6 Sep 2023 09:11:45 GMT Subject: RFR: 8315444: Convert test/jdk/tools to Classfile API [v2] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 23:33:05 GMT, Chen Liang wrote: >> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision: >> >> migrate test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java use Classfile API > > test/jdk/tools/lib/tests/JImageValidator.java line 225: > >> 223: >> 224: public static void readClass(byte[] clazz) throws IOException { >> 225: Classfile.of().parse(clazz); > > Notice that the old API might throw different exceptions compared to the new one; the new one is lazy, e.g. if there's broken interface entry but the interfaces are not queried, no exception is thrown. You are right, however original `ClassFile::read` also does not represent much of a validation. Stronger verification can by applied by asserting no verify errors returned from `ClassModel::verify`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15529#discussion_r1316981223 From jvernee at openjdk.org Wed Sep 6 10:04:35 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Sep 2023 10:04:35 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v11] 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: Fix typo in doc Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/de3e7479..5e439da8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 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 jvernee at openjdk.org Wed Sep 6 10:04:38 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Sep 2023 10:04:38 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v10] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 21:10:47 GMT, Paul Sandoz wrote: >> Jorn Vernee has updated the pull request incrementally with five additional commits since the last revision: >> >> - 8315096: Allowed access modes in memory segment should depend on layout alignment >> >> Reviewed-by: psandoz >> - Add missing @implSpec to AddressLayout >> >> Reviewed-by: pminborg >> - Fix misc typos in FFM API javadoc >> >> Reviewed-by: jvernee >> - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two) >> >> Reviewed-by: pminborg >> - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle >> >> Reviewed-by: jvernee > > src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 443: > >> 441: * >> 442: * {@snippet lang = "java": >> 443: * offset = this.offsetHandle(P).invokeExact(B, I1, I2, ... In); > > Suggestion: > > * O = this.offsetHandle(P).invokeExact(B, I1, I2, ... In); > > To align with the use of `O` later on. Good catch. The `O` later on was added separately, hence they are out of sync. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1317041205 From jvernee at openjdk.org Wed Sep 6 10:04:40 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Sep 2023 10:04:40 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v11] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 21:56:54 GMT, Paul Sandoz wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in doc >> >> Co-authored-by: Paul Sandoz > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8027: > >> 8025: * @since 19 >> 8026: */ >> 8027: @PreviewFeature(feature=PreviewFeature.Feature.FOREIGN) > > Unused import to `PreviewFeature`, and possibly others too. Thanks. I did a sweep of the foreign packages and there don't seem to be any other uses. There were also some other unused imports in this file that I'll remove. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1317045735 From duke at openjdk.org Wed Sep 6 10:20:14 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 10:20:14 GMT Subject: RFR: 8315585: Optimization for decimal to string [v5] In-Reply-To: References: Message-ID: <8qz9waHFlNxaf0x1BrHWQ-Gm8V-RUdOzUZeX4alzaxE=.ddac0aca-c5d1-4681-afd3-f6a0b5aeb09f@github.com> > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request incrementally with one additional commit since the last revision: add testcase & bug fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/d840e3fc..0c5833f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=03-04 Stats: 131 lines in 3 files changed: 127 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From duke at openjdk.org Wed Sep 6 10:20:34 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 10:20:34 GMT Subject: RFR: 8315585: Optimization for decimal to string [v4] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 03:34:04 GMT, ??? wrote: >> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. >> >> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. >> >> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. >> >> The performance data is as follows: >> >> ## 1. benchmark script >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.math.BigDecimals.*ToPlainString" >> make test TEST="micro:java.math.BigDecimals.*ToEngineering" >> >> >> ## 2. benchmark environment >> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) >> * cpu intel xeon sapphire rapids (x64) >> >> ## 3. benchmark result >> >> -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) >> -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op >> -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op >> -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) >> +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) >> +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) >> +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op >> -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op >> -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op >> -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) >> +BigDecimals.testLargeToEngineeringStr... > > ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into optimization_for_decimal_to_string > - Merge branch 'master' into optimization_for_decimal_to_string > - BigInteger use a separate jla > - update copyright info > - optimization for decimal to string I have added test, set breakpoints by debugging to ensure that all branches of changed code have been tested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1708065884 From qamai at openjdk.org Wed Sep 6 10:22:44 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 6 Sep 2023 10:22:44 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Tue, 5 Sep 2023 00:10:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright date info We can consolidate the implementation of `Integer::toString` and `Integer::toUnsignedString` by taking the absolute value of the signed integer and move the later operation to unsigned domain. This helps remove the need of relying on much more expensive `BigInteger` when invoking `Long::toUnsignedString` and may improve the performance of `Integer::toUnsignedString` a little bit. Computing in unsigned domain is also faster (`x s/ 100 = (x * 1374389535) >> 37 - (x >> 31)` while `x u/ 100 = (x * 1374389535) >>> 37`). Folding of unsigned division is still in review but we can use `(int)(((long)x * 1374389535) >>> 37)` for `int` and `mulhi(x >>> 2, 2951479051793528259) >>> 2` for `long` directly. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1708068941 From jvernee at openjdk.org Wed Sep 6 10:48:06 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Sep 2023 10:48:06 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v12] 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: Paul's review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/5e439da8..afcfa2b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=10-11 Stats: 15 lines in 5 files changed: 0 ins; 10 del; 5 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 mdoerr at openjdk.org Wed Sep 6 10:48:52 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 6 Sep 2023 10:48:52 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v11] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 10:04:35 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: > > Fix typo in doc > > Co-authored-by: Paul Sandoz Please adapt the new `LinuxPPC64Linker` when merging: diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java b/src/java.base/share/classes/jdk/inter nal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java index 150687d4078..7cf2d524bff 100644 --- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java @@ -27,15 +27,22 @@ import jdk.internal.foreign.abi.AbstractLinker; import jdk.internal.foreign.abi.LinkerOptions; +import jdk.internal.foreign.abi.SharedUtils; import jdk.internal.foreign.abi.ppc64.CallArranger; import java.lang.foreign.FunctionDescriptor; +import java.lang.foreign.MemoryLayout; +import java.lang.foreign.ValueLayout; import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodType; import java.nio.ByteOrder; +import java.util.Map; public final class LinuxPPC64Linker extends AbstractLinker { + static final Map CANONICAL_LAYOUTS = + SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT); + public static LinuxPPC64Linker getInstance() { final class Holder { private static final LinuxPPC64Linker INSTANCE = new LinuxPPC64Linker(); @@ -62,4 +69,9 @@ protected UpcallStubFactory arrangeUpcall(MethodType targetType, FunctionDescrip protected ByteOrder linkerByteOrder() { return ByteOrder.BIG_ENDIAN; } + + @Override + public Map canonicalLayouts() { + return CANONICAL_LAYOUTS; + } } The `test/jdk/java/foreign` tests have passed on both, linux PPC64 and PPC64le. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1708107829 From jvernee at openjdk.org Wed Sep 6 10:54:46 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Sep 2023 10:54:46 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v11] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 10:46:33 GMT, Martin Doerr wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in doc >> >> Co-authored-by: Paul Sandoz > > Please adapt the new `LinuxPPC64Linker` when merging: > > diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java b/src/java.base/share/classes/jdk/inter > nal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java > index 150687d4078..7cf2d524bff 100644 > --- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java > +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java > @@ -27,15 +27,22 @@ > > import jdk.internal.foreign.abi.AbstractLinker; > import jdk.internal.foreign.abi.LinkerOptions; > +import jdk.internal.foreign.abi.SharedUtils; > import jdk.internal.foreign.abi.ppc64.CallArranger; > > import java.lang.foreign.FunctionDescriptor; > +import java.lang.foreign.MemoryLayout; > +import java.lang.foreign.ValueLayout; > import java.lang.invoke.MethodHandle; > import java.lang.invoke.MethodType; > import java.nio.ByteOrder; > +import java.util.Map; > > public final class LinuxPPC64Linker extends AbstractLinker { > > + static final Map CANONICAL_LAYOUTS = > + SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT); > + > public static LinuxPPC64Linker getInstance() { > final class Holder { > private static final LinuxPPC64Linker INSTANCE = new LinuxPPC64Linker(); > @@ -62,4 +69,9 @@ protected UpcallStubFactory arrangeUpcall(MethodType targetType, FunctionDescrip > protected ByteOrder linkerByteOrder() { > return ByteOrder.BIG_ENDIAN; > } > + > + @Override > + public Map canonicalLayouts() { > + return CANONICAL_LAYOUTS; > + } > } > > The `test/jdk/java/foreign` tests have passed on both, linux PPC64 and PPC64le. @TheRealMDoerr Thanks for the patch, will include it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1708114403 From jvernee at openjdk.org Wed Sep 6 10:54:48 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Sep 2023 10:54:48 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v10] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 21:01:00 GMT, Paul Sandoz wrote: >> Jorn Vernee has updated the pull request incrementally with five additional commits since the last revision: >> >> - 8315096: Allowed access modes in memory segment should depend on layout alignment >> >> Reviewed-by: psandoz >> - Add missing @implSpec to AddressLayout >> >> Reviewed-by: pminborg >> - Fix misc typos in FFM API javadoc >> >> Reviewed-by: jvernee >> - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two) >> >> Reviewed-by: pminborg >> - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle >> >> Reviewed-by: jvernee > > src/java.base/share/classes/java/lang/foreign/Linker.java line 152: > >> 150: *

>> 151: * The following table shows some examples of how C types are modelled in Linux/x64 (all the examples provided >> 152: * here will assume these platform-dependent mappings): > > Up to you, but it might be useful to link to the ABI specifications if the links are considered stable. There is this: https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf I'm not sure how stable this is. I don't think that website is an authoritative source. (at least, not to the degree it is for e.g. AArch64: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#595homogeneous-aggregates). Note also that is a draft. I think the final version is paywalled. Alternatively, we could refer to the name only: "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (or "x86-64 psABI") Then people can google for themselves and find it. For instance, [this SO question](https://stackoverflow.com/a/40348010) points to a gitlab repo with a more up to date version: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1317100703 From coffeys at openjdk.org Wed Sep 6 11:05:58 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 6 Sep 2023 11:05:58 GMT Subject: RFR: 8315696: SignedLoggerFinderTest.java test failed Message-ID: <2Z7k7CgJemfnuEvZApN87RpMEO34MTN2a7YUxDSL_tc=.f1b92993-1742-4d92-be8c-5c8944a51191@github.com> Update the recently added LoggerFinder tests to cater for a possible condition where the test finishes before the boot logger executor service has flushed its pending data. By simulating a slow thread in the ExecutorService used in BootstrapLogger, I was able to reproduce the issue described. Adding the `BootstrapLoggerUtils.awaitPending();` call allows the tests to pass. ------------- Commit messages: - refactory testlibrary name - 8315696 Changes: https://git.openjdk.org/jdk/pull/15571/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15571&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315696 Stats: 147 lines in 8 files changed: 74 ins; 64 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/15571.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15571/head:pull/15571 PR: https://git.openjdk.org/jdk/pull/15571 From jvernee at openjdk.org Wed Sep 6 11:20:18 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Sep 2023 11:20:18 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v13] In-Reply-To: References: Message-ID: <97cANIvE2FMHvs_WDQ4BXFxfnjgtJ7fLfbLfM_aCONA=.a832d87f-5847-492b-9843-2b88346090f1@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 with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - PPC linker changes - Merge branch 'master' into JEP22 - Paul's review comments - Fix typo in doc Co-authored-by: Paul Sandoz - 8315096: Allowed access modes in memory segment should depend on layout alignment Reviewed-by: psandoz - Add missing @implSpec to AddressLayout Reviewed-by: pminborg - Fix misc typos in FFM API javadoc Reviewed-by: jvernee - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two) Reviewed-by: pminborg - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle Reviewed-by: jvernee - remove unsupported linker test - ... and 24 more: https://git.openjdk.org/jdk/compare/62a953f4...b8bb791f ------------- Changes: https://git.openjdk.org/jdk/pull/15103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=12 Stats: 3176 lines in 238 files changed: 1480 ins; 951 del; 745 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 dfuchs at openjdk.org Wed Sep 6 11:54:38 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 6 Sep 2023 11:54:38 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. jmx, jndi, and net changes LGTM ------------- PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613147541 From jvernee at openjdk.org Wed Sep 6 12:01:27 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Sep 2023 12:01:27 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v14] 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: remove reference to allocateArray ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/b8bb791f..52df58f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=12-13 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 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 asotona at openjdk.org Wed Sep 6 12:28:05 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 6 Sep 2023 12:28:05 GMT Subject: RFR: 8313452: Improve Classfile API attributes handling safety [v2] In-Reply-To: References: Message-ID: > This PR improved Classfile API attributes handling safety by introduction of attribute stability indicator > and by extension of UnknownAttributesOption to more general AttributesProcessingOption. Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - fixed javadoc wording - HAZMAT renamed to UNSTABLE no filtering on read filtering on write only for bound attributes - Merge branch 'master' into JDK-8313452-attributes-safety # Conflicts: # src/java.base/share/classes/jdk/internal/classfile/Classfile.java - Merge branch 'JDK-8312491-snippets' into JDK-8313452-attributes-safety - added notes to attributes - fixing javadoc - fixing javadoc - fixing javadoc - fixing javadoc - removed extra lines - ... and 13 more: https://git.openjdk.org/jdk/compare/744b3970...ce77e2ae ------------- Changes: https://git.openjdk.org/jdk/pull/15101/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15101&range=01 Stats: 479 lines in 10 files changed: 374 ins; 29 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/15101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15101/head:pull/15101 PR: https://git.openjdk.org/jdk/pull/15101 From volker.simonis at gmail.com Wed Sep 6 13:02:55 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 6 Sep 2023 15:02:55 +0200 Subject: Question on why sun.management MBeans are not exported? Message-ID: Hi, I recently looked for an easy way to get the CPU time spent by JIT-compiler and GC threads in Java (e.g exported by IBM J9's JvmCpuMonitorMXBean [0]). An easy way to achieve this is in OpenJDK is by using the "sun.management.HotspotInternal" MBean which exports the "sun.management:type=HotspotThreading" MBean with the attributes InternalThreadCount/InternalThreadCpuTimes (among other useful HotSpot internal counters and metrics). Up until JDK 16/17 the usage of the "sun.management.HotspotInternal" MBean was straightforward, although it resulted in an illegal reflective access warning since JDK 9. Since JDK 17 its usage requires the " --add-exports java.management/sun.management=ALL-UNNAMED" for the monitored JVM. I wonder why "sun.management" was encapsulated in the first place? I understand that it is not an "officially supported" API, but I find it still quite useful. If we really don't want to export it, I wonder why we are maintaining it at all (we even have JTreg tests for it under "test/jdk/sun/management"), because in the current configuration it isn't particularly useful. Notice that jconsole supports the "sun.management.HotspotInternal" MBean if started with "J-Djconsole.showUnsupported=true" and the "java.management" module kind of tries to support jconsole with the following exports: exports sun.management to jdk.jconsole, jdk.management, jdk.management.agent; However, that doesn't help even if jconsole monitors itself (for the general case, where jconsole monitors a different JVM process it can't work anyway). With JDK 16 and "--illegal-access=debug" we can see why: WARNING: Illegal reflective access by sun.reflect.misc.Trampoline to method sun.management.HotspotThreadMBean.getInternalThreadCount() at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260) at java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112) at java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46) at java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) at java.management/com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83) at java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206) at java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttributes(MBeanSupport.java:213) at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttributes(DefaultMBeanServerInterceptor.java:701) at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttributes(JmxMBeanServer.java:705) Notice that 'sun.reflect.misc.Trampoline' is loaded by a custom class loader ('java.base/sun.reflect.misc.MethodUtil') and not considered part of the base module. So to cut a long story short, I see several options: 1. Publicly export sun.management and restore the JDK 8 (or pre JDK 16) behavior. This would certainly require some polishing (e.g. some of the corresponding JVM functionality has already been removed [1]) but I think it could still be quite useful. 2. Port the useful functionality from the "sun.management" MBeans to corresponding "com.sun.management" MBeans and remove the "sun.management" MBeans. 3. Remove the "sun.management" MBeans without substitution. What do you think? Thank you and best regards, Volker [0] https://www.ibm.com/docs/en/sdk-java-technology/8?topic=interfaces-language-management [1] https://bugs.openjdk.org/browse/JDK-8134607 From dl at openjdk.org Wed Sep 6 13:07:10 2023 From: dl at openjdk.org (Doug Lea) Date: Wed, 6 Sep 2023 13:07:10 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v25] 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: Allow ThreadGroup access in tck tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14301/files - new: https://git.openjdk.org/jdk/pull/14301/files/787c1cb1..f2dd803e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=23-24 Stats: 13 lines in 2 files changed: 1 ins; 9 del; 3 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 aivanov at openjdk.org Wed Sep 6 13:09:38 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 6 Sep 2023 13:09:38 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. Client changes look good. I've looked through all the files, other files look good too. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613295743 From duke at openjdk.org Wed Sep 6 13:21:40 2023 From: duke at openjdk.org (ExE Boss) Date: Wed, 6 Sep 2023 13:21:40 GMT Subject: RFR: 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex methods are confusing [v2] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 15:25:04 GMT, Adam Sotona wrote: >> Classfile API `ConstantPool::entryCount` and `ConstantPool::entryByIndex` methods are confusing and unsafe to use without knowledge of constant pool specification. >> This patch renames `ConstantPool::entryCount` to `ConstantPool::size` and adds checks to `ConstantPool::entryByIndex` for invalid or unusable indexes. >> `ConstantPool` newly extends `Iterable` for simplified user iteration over all pool entries. >> Range checks for invalid index have been added also to `ConstantPoo::bootstrapMethodEntry` methods and several `@jvms` javadoc tags have been added to pool entries. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed tests src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 76: > 74: } > 75: }; > 76: } This?iterator isn?t?entirely?correct, because?if the?constant?pool is?modified between?the?call to?`hasNext()` and?`next()`, then?it?may throw?`NoSuchElementException`. Additionally, `hasNext()` can?go?from returning?`false` to?returning?`true`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15567#discussion_r1316903003 From redestad at openjdk.org Wed Sep 6 13:43:01 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 6 Sep 2023 13:43:01 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements Message-ID: This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: Name Cnt Base Error Test Error Unit Diff% HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) :gc.count 15 3,000 0,000 counts :gc.time 3 2,000 ms HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) :gc.count 15 3,000 0,000 counts :gc.time 3 2,000 ms HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) :gc.count 15 0,000 0,000 counts HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) :gc.count 15 3,000 0,000 counts :gc.time 3 2,000 ms HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) :gc.count 15 0,000 0,000 counts HexFormatBench.toHexLowerCached 15 0,201 ? 0,002 0,114 ? 0,001 us/op 43,0% (p = 0,000*) :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,2% (p = 0,116 ) :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -43,1% (p = 0,000*) :gc.count 15 0,000 0,000 counts HexFormatBench.toHexUpper 15 0,146 ? 0,002 0,114 ? 0,001 us/op 21,6% (p = 0,000*) :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec 0,0% (p = 0,668 ) :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -21,5% (p = 0,000*) :gc.count 15 0,000 0,000 counts HexFormatBench.toHexUpperCached 15 0,199 ? 0,002 0,116 ? 0,003 us/op 41,7% (p = 0,000*) :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec 0,0% (p = 0,684 ) :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -41,7% (p = 0,000*) :gc.count 15 0,000 0,000 counts * = significant Invariant parameters used by above microbenchmarks: size: 512 ------------- Commit messages: - 8315789: Minor HexFormat performance improvements Changes: https://git.openjdk.org/jdk/pull/15591/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15591&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315789 Stats: 184 lines in 2 files changed: 156 ins; 9 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/15591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15591/head:pull/15591 PR: https://git.openjdk.org/jdk/pull/15591 From Alan.Bateman at oracle.com Wed Sep 6 13:47:23 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Sep 2023 14:47:23 +0100 Subject: Question on why sun.management MBeans are not exported? In-Reply-To: References: Message-ID: <1535aa6e-6865-d885-3930-df7f9ebcb4b4@oracle.com> On 06/09/2023 14:02, Volker Simonis wrote: > : > > I wonder why "sun.management" was encapsulated in the first place? I > understand that it is not an "officially supported" API, but I find it > still quite useful. sun.management.* is JDK internal so not something for code outside the JDK to use directly. The only sun.* packages that are exported to all modules are the "critical internal APIs" in the jdk.unsupported module. JEP 260 has the details. > : > > So to cut a long story short, I see several options: > > 1. Publicly export sun.management and restore the JDK 8 (or pre JDK > 16) behavior. This would certainly require some polishing (e.g. some > of the corresponding JVM functionality has already been removed [1]) > but I think it could still be quite useful. > 2. Port the useful functionality from the "sun.management" MBeans to > corresponding "com.sun.management" MBeans and remove the > "sun.management" MBeans. > 3. Remove the "sun.management" MBeans without substitution. > > What do you think? If there are JDK-specific or HotSpot VM specific features where there is a compelling case for a management interface then com.sun.management is good place to prototype new APIs. You may already be familiar with com.sun.management.HotSpotDiagnosticMBean. -Alan From duke at openjdk.org Wed Sep 6 14:03:43 2023 From: duke at openjdk.org (ExE Boss) Date: Wed, 6 Sep 2023 14:03:43 GMT Subject: RFR: 8313452: Improve Classfile API attributes handling safety [v2] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 12:28:05 GMT, Adam Sotona wrote: >> This PR improved Classfile API attributes handling safety by introduction of attribute stability indicator >> and by extension of UnknownAttributesOption to more general AttributesProcessingOption. > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - fixed javadoc wording > - HAZMAT renamed to UNSTABLE > no filtering on read > filtering on write only for bound attributes > - Merge branch 'master' into JDK-8313452-attributes-safety > > # Conflicts: > # src/java.base/share/classes/jdk/internal/classfile/Classfile.java > - Merge branch 'JDK-8312491-snippets' into JDK-8313452-attributes-safety > - added notes to attributes > - fixing javadoc > - fixing javadoc > - fixing javadoc > - fixing javadoc > - removed extra lines > - ... and 13 more: https://git.openjdk.org/jdk/compare/744b3970...ce77e2ae src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java line 59: > 57: if (a instanceof UnboundAttribute || > 58: 5 - a.attributeMapper().attributeStability().ordinal() > 59: > context.attributesProcessingOption().ordinal()) { Maybe?extract the?`5 -?a.attributeMapper().attributeStability().ordinal() >?context.attributesProcessingOption().ordinal()`?check into?a?helper?method, as?the?current?expression is?too?noisy: import jdk.internal.classfile.AttributeMapper.AttributeStability; import jdk.internal.classfile.Classfile.AttributesProcessingOption; private static final int ATTRIBUTE_STABILITY_COUNT = AttributeStability.values().length; public static boolean isAttributeAllowed( final AttributeStability stability, final AttributesProcessingOption processingOption ) { return ATTRIBUTE_STABILITY_COUNT - stability.ordinal() > processingOption.ordinal(); } Also, the?magic?number should?probably be?replaced with?a?constant storing?the?value of?`AttributeStability.values().length`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15101#discussion_r1317326262 From asotona at openjdk.org Wed Sep 6 14:17:41 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 6 Sep 2023 14:17:41 GMT Subject: RFR: 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex methods are confusing [v2] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 08:10:12 GMT, ExE Boss wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed tests > > src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 76: > >> 74: } >> 75: }; >> 76: } > > This?iterator isn?t?entirely?correct, because?if the?constant?pool is?modified between?the?call to?`hasNext()` and?`next()`, then?it?may throw?`NoSuchElementException`. > > Additionally, `hasNext()` can?go?from returning?`false` to?returning?`true`. The size of the pool can never go down so the iterator should behave correctly even when underlying pool is modified. Primary purpose of the iterator is to replace not very intuitive (and frequently coded wrong - even in our own tests) for loop iteration: for(int index = 1; index < pool.size(); index += pool.entryByIndex(index).width()) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15567#discussion_r1317355090 From duke at openjdk.org Wed Sep 6 14:41:44 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 14:41:44 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Wed, 6 Sep 2023 10:20:17 GMT, Quan Anh Mai wrote: > We can consolidate the implementation of `Integer::toString` and `Integer::toUnsignedString` by taking the absolute value of the signed integer and move the later operation to unsigned domain. This helps remove the need of relying on much more expensive `BigInteger` when invoking `Long::toUnsignedString` and may improve the performance of `Integer::toUnsignedString` a little bit. Computing in unsigned domain is also faster (`x s/ 100 = (x * 1374389535) >> 37 - (x >> 31)` while `x u/ 100 = (x * 1374389535) >>> 37`). Folding of unsigned division is still in review but we can use `(int)(((long)x * 1374389535) >>> 37)` for `int` and `mulhi(x >>> 2, 2951479051793528259) >>> 2` for `long` directly. > > Thanks. According to your suggestion, I tested the following code, and the performance has not improved. I'm not sure this implementation is what you think. static final byte[] INTEGER_MIN_BYTES = new byte[] {45, 50, 49, 52, 55, 52, 56, 51, 54, 52, 56}; static int getChars(int i, int index, byte[] buf) { // Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. int q, r; int charPos = index; if (i == Integer.MIN_VALUE) { int len = INTEGER_MIN_BYTES.length; System.arraycopy(INTEGER_MIN_BYTES, 0, buf, index - len, len); return index - len; } boolean negative = i < 0; if (negative) { i = -i; } // Generate two digits per iteration while (i >= 100) { // really: q = i / 100 q = (int) ((((long) i) * 1374389535) >>> 37); r = i - (q * 100); i = q; charPos -= 2; assert charPos >= 0 && charPos < buf.length : "Trusted caller missed bounds check"; UNSAFE.putShortUnaligned(buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos, PACKED_DIGITS[r], false); } // We know there are at most two digits left at this point. if (i > 9) { charPos -= 2; assert charPos >= 0 && charPos < buf.length : "Trusted caller missed bounds check"; UNSAFE.putShortUnaligned(buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos, PACKED_DIGITS[i], false); } else { buf[--charPos] = (byte)('0' + i); } if (negative) { buf[--charPos] = (byte)'-'; } return charPos; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1708502965 From mbaesken at openjdk.org Wed Sep 6 14:54:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Sep 2023 14:54:54 GMT Subject: RFR: JDK-8315751: RandomTestBsi1999 fails often with timeouts on Linux ppc64le Message-ID: The test RandomTestBsi1999 fails often with timeouts on Linux ppc64le; even when it succeeds the test takes a lot of time and is close to timing out. Probably we should increase the timeout value for this test. ------------- Commit messages: - JDK-8315751 Changes: https://git.openjdk.org/jdk/pull/15594/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15594&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315751 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15594/head:pull/15594 PR: https://git.openjdk.org/jdk/pull/15594 From asotona at openjdk.org Wed Sep 6 15:03:24 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 6 Sep 2023 15:03:24 GMT Subject: RFR: 8313452: Improve Classfile API attributes handling safety [v3] In-Reply-To: References: Message-ID: > This PR improved Classfile API attributes handling safety by introduction of attribute stability indicator > and by extension of UnknownAttributesOption to more general AttributesProcessingOption. Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: magic moved to Util::isAttributeAllowed and fixed possible NPE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15101/files - new: https://git.openjdk.org/jdk/pull/15101/files/ce77e2ae..392ba560 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15101&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15101&range=01-02 Stats: 20 lines in 2 files changed: 12 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15101/head:pull/15101 PR: https://git.openjdk.org/jdk/pull/15101 From asotona at openjdk.org Wed Sep 6 15:03:26 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 6 Sep 2023 15:03:26 GMT Subject: RFR: 8313452: Improve Classfile API attributes handling safety [v3] In-Reply-To: References: Message-ID: <7ypNj9IwC9nWdo2rl3qIQKoj9PACA3sR9cptxyDsYMA=.ebedb400-1491-41b6-99db-c6e510712676@github.com> On Wed, 6 Sep 2023 13:54:28 GMT, ExE Boss wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> magic moved to Util::isAttributeAllowed and fixed possible NPE > > src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java line 59: > >> 57: if (a instanceof UnboundAttribute || >> 58: 5 - a.attributeMapper().attributeStability().ordinal() >> 59: > context.attributesProcessingOption().ordinal()) { > > Maybe?extract the?`5 -?a.attributeMapper().attributeStability().ordinal() >?context.attributesProcessingOption().ordinal()`?check into?a?helper?method, as?the?current?expression is?too?noisy: > > import jdk.internal.classfile.AttributeMapper.AttributeStability; > import jdk.internal.classfile.Classfile.AttributesProcessingOption; > > private static final int ATTRIBUTE_STABILITY_COUNT = AttributeStability.values().length; > public static boolean isAttributeAllowed( > final AttributeStability stability, > final AttributesProcessingOption processingOption > ) { > return ATTRIBUTE_STABILITY_COUNT - stability.ordinal() > processingOption.ordinal(); > } > > > Also, the?magic?number should?probably be?replaced with?a?constant storing?the?value of?`AttributeStability.values().length`. Fixed, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15101#discussion_r1317422600 From alanb at openjdk.org Wed Sep 6 15:04:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Sep 2023 15:04:56 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v3] In-Reply-To: References: Message-ID: > In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM. > > The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition. > > Testing: tier1-5 Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Move transition check to JfrVframeStream ctor - Merge - Check for transition during stack walk for synchronous case - Merge - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15492/files - new: https://git.openjdk.org/jdk/pull/15492/files/18f63cbd..507ae919 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15492&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15492&range=01-02 Stats: 6688 lines in 179 files changed: 5237 ins; 969 del; 482 mod Patch: https://git.openjdk.org/jdk/pull/15492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15492/head:pull/15492 PR: https://git.openjdk.org/jdk/pull/15492 From volker.simonis at gmail.com Wed Sep 6 15:17:26 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 6 Sep 2023 17:17:26 +0200 Subject: Question on why sun.management MBeans are not exported? In-Reply-To: <1535aa6e-6865-d885-3930-df7f9ebcb4b4@oracle.com> References: <1535aa6e-6865-d885-3930-df7f9ebcb4b4@oracle.com> Message-ID: On Wed, Sep 6, 2023 at 3:47?PM Alan Bateman wrote: > > On 06/09/2023 14:02, Volker Simonis wrote: > > : > > > > I wonder why "sun.management" was encapsulated in the first place? I > > understand that it is not an "officially supported" API, but I find it > > still quite useful. > sun.management.* is JDK internal so not something for code outside the > JDK to use directly. The only sun.* packages that are exported to all > modules are the "critical internal APIs" in the jdk.unsupported module. > JEP 260 has the details. I'm familiar with JEP 260. But wouldn't you agree that an "encapsulated" monitoring API is an oxymoron? A monitoring API is by design intended for external usage and completely useless to the platform itself. There's no single usage of the "sun.management" MBeans in the JDK itself (except for jconsole where the encapsulation broke it). My assumption is that the corresponding MBeans in "sun.management" are there for historic reasons (added in JDK 1.5) and would have made much more sense in "com.sun.management" package. But I doubt that they can be classified in the "internal implementation details of the JDK and never intended for external use? category of JEP 260. Anyway, if you classify the MBeans in "sun.management" as non-critical internal APIs (with respect to JEP 260) but without any "internal" usage, than we should really remove them, right, because an internal API without any internal usage doesn't make any sense? I'll then try to come up with a proposal to port some of the more useful MBeans functionality in "sun.management" to "com.sun.management". Thank you and best regards, Volker > > > > : > > > > So to cut a long story short, I see several options: > > > > 1. Publicly export sun.management and restore the JDK 8 (or pre JDK > > 16) behavior. This would certainly require some polishing (e.g. some > > of the corresponding JVM functionality has already been removed [1]) > > but I think it could still be quite useful. > > 2. Port the useful functionality from the "sun.management" MBeans to > > corresponding "com.sun.management" MBeans and remove the > > "sun.management" MBeans. > > 3. Remove the "sun.management" MBeans without substitution. > > > > What do you think? > If there are JDK-specific or HotSpot VM specific features where there is > a compelling case for a management interface then com.sun.management is > good place to prototype new APIs. You may already be familiar with > com.sun.management.HotSpotDiagnosticMBean. > > -Alan From duke at openjdk.org Wed Sep 6 15:21:47 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 15:21:47 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: <-jH50CCsYy3uFv9h36jEKIiyF2FslTBh_ay-9PoVZGM=.2d4331dd-e2b4-49b3-8500-6f89f1ed3cd4@github.com> On Wed, 6 Sep 2023 10:20:17 GMT, Quan Anh Mai wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> update copyright date info > > We can consolidate the implementation of `Integer::toString` and `Integer::toUnsignedString` by taking the absolute value of the signed integer and move the later operation to unsigned domain. This helps remove the need of relying on much more expensive `BigInteger` when invoking `Long::toUnsignedString` and may improve the performance of `Integer::toUnsignedString` a little bit. Computing in unsigned domain is also faster (`x s/ 100 = (x * 1374389535) >> 37 - (x >> 31)` while `x u/ 100 = (x * 1374389535) >>> 37`). Folding of unsigned division is still in review but we can use `(int)(((long)x * 1374389535) >>> 37)` for `int` and `mulhi(x >>> 2, 2951479051793528259) >>> 2` for `long` directly. > > Thanks. @merykitty This PR has been more than 2 months, 19 commits, 55 conversations, the optimization of this PR is mainly to merge two caches into one cache and use unsafe.setShort to write two numbers at a time. Can we finish merging this PR first, and then open a new PR to implement your suggestion? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1708586068 From rgiulietti at openjdk.org Wed Sep 6 15:32:52 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 6 Sep 2023 15:32:52 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote: > This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. > > This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: > > > Name Cnt Base Error Test Error Unit Diff% > HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) > :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) > :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 0,000 0,000 counts > HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) > :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) > :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) > :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) > :gc.count 15 0,000 0,000 ... src/java.base/share/classes/java/util/HexFormat.java line 644: > 642: return (char)('a' - 10 + value); > 643: } > 644: return (char)('A' - 10 + value); Not sure if this would adversely impact performance, but what about factoring out these lines in a private method? They are repeated in `toHighHexDigit`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15591#discussion_r1317472587 From redestad at openjdk.org Wed Sep 6 15:33:53 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 6 Sep 2023 15:33:53 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Tue, 5 Sep 2023 00:10:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright date info I agree that this is good to go and that ideas to improve this further be explored separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1708613358 From rriggs at openjdk.org Wed Sep 6 15:37:42 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Sep 2023 15:37:42 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote: > This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. > > This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: > > > Name Cnt Base Error Test Error Unit Diff% > HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) > :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) > :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 0,000 0,000 counts > HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) > :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) > :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) > :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) > :gc.count 15 0,000 0,000 ... src/java.base/share/classes/java/util/HexFormat.java line 183: > 181: LOWERCASE, > 182: UPPERCASE > 183: } Instead of an enum cache the "A" or "a" for direct use. `private final char caseBase;` Initialize it in the constructor. src/java.base/share/classes/java/util/HexFormat.java line 644: > 642: return (char)('a' - 10 + value); > 643: } > 644: return (char)('A' - 10 + value); Would caching the upper/lower case base avoid a branch? Suggestion: return (char)(caseBase - 10 + value); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15591#discussion_r1317479579 PR Review Comment: https://git.openjdk.org/jdk/pull/15591#discussion_r1317480167 From tprinzing at openjdk.org Wed Sep 6 15:57:41 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Wed, 6 Sep 2023 15:57:41 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: References: Message-ID: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com> On Tue, 22 Aug 2023 07:31:36 GMT, Alan Bateman wrote: > > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops > > Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops. I think it's useful if trying to trace the calls (i.e. set to 0ms). Apparently the security manager was being used for that by some. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1708657617 From iris at openjdk.org Wed Sep 6 16:02:41 2023 From: iris at openjdk.org (Iris Clark) Date: Wed, 6 Sep 2023 16:02:41 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format. > > It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files. Thanks for fixing! ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613704179 From psandoz at openjdk.org Wed Sep 6 16:06:47 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 6 Sep 2023 16:06:47 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v10] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 10:50:59 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/java/lang/foreign/Linker.java line 152: >> >>> 150: *

>>> 151: * The following table shows some examples of how C types are modelled in Linux/x64 (all the examples provided >>> 152: * here will assume these platform-dependent mappings): >> >> Up to you, but it might be useful to link to the ABI specifications if the links are considered stable. > > [This SO question](https://stackoverflow.com/a/40348010) points to a gitlab repo that seems to have the latest version: https://gitlab.com/x86-psABIs/x86-64-ABI But, I'm not sure how stable that is, or if that's an authoritative source. > > Alternatively, we could refer to the name only: "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (or "x86-64 psABI") Then people can google for themselves and find it. Yeah, its hard to find the official and latest version. Referring to the full title will help. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1317517319 From erikj at openjdk.org Wed Sep 6 16:09:41 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 6 Sep 2023 16:09:41 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 23:12:51 GMT, Chris Plummer wrote: > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools. Do you think I should revert them? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708676439 From redestad at openjdk.org Wed Sep 6 16:09:41 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 6 Sep 2023 16:09:41 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 15:34:54 GMT, Roger Riggs wrote: >> This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. >> >> This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: >> >> >> Name Cnt Base Error Test Error Unit Diff% >> HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) >> :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) >> :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 3,000 0,000 counts >> :gc.time 3 2,000 ms >> HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) >> :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) >> :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 3,000 0,000 counts >> :gc.time 3 2,000 ms >> HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) >> :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) >> :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 0,000 0,000 counts >> HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) >> :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) >> :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 3,000 0,000 counts >> :gc.time 3 2,000 ms >> HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) >> :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) >> :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) >> :gc.... > > src/java.base/share/classes/java/util/HexFormat.java line 644: > >> 642: return (char)('a' - 10 + value); >> 643: } >> 644: return (char)('A' - 10 + value); > > Would caching the upper/lower case base avoid a branch? > Suggestion: > > return (char)(caseBase - 10 + value); I tried this but it looks like it is marginally slower - plausibly the code I have means the JIT eliminates the untaken branch and constant folds this neatly. I'll do some digging.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15591#discussion_r1317521509 From redestad at openjdk.org Wed Sep 6 16:13:41 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 6 Sep 2023 16:13:41 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: <-W8u-JpaBk6-YzEGDbun13rl2lvK0m2Pxq_XLAZRSEs=.1d1a7c04-ef8f-4383-95b2-13907e725ae8@github.com> On Wed, 6 Sep 2023 15:29:45 GMT, Raffaello Giulietti wrote: >> This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. >> >> This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: >> >> >> Name Cnt Base Error Test Error Unit Diff% >> HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) >> :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) >> :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 3,000 0,000 counts >> :gc.time 3 2,000 ms >> HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) >> :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) >> :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 3,000 0,000 counts >> :gc.time 3 2,000 ms >> HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) >> :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) >> :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 0,000 0,000 counts >> HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) >> :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) >> :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 3,000 0,000 counts >> :gc.time 3 2,000 ms >> HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) >> :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) >> :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) >> :gc.... > > src/java.base/share/classes/java/util/HexFormat.java line 644: > >> 642: return (char)('a' - 10 + value); >> 643: } >> 644: return (char)('A' - 10 + value); > > Not sure if this would adversely impact performance, but what about factoring out these lines in a private method? They are repeated in `toHighHexDigit`. Surprisingly this does carry some cost in the microbenchmarks on my M1. Might be noise, but it seems rather consistent so I'll need to investigate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15591#discussion_r1317525305 From rriggs at openjdk.org Wed Sep 6 16:13:46 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Sep 2023 16:13:46 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Tue, 5 Sep 2023 00:10:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright date info I'd be more comfortable replacing the use of Unsafe with either the ByteArray functions or VarHandles. Using VarHandles will enable future optimizations, whereas Unsafe is a primitive tool and is brittle. ------------- Changes requested by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14699#pullrequestreview-1613724602 From lkorinth at openjdk.org Wed Sep 6 16:24:45 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 6 Sep 2023 16:24:45 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 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 one additional commit since the last revision: > > fix static import I think you are missing the point. If you take a look at [the parent bug of the sub task](https://bugs.openjdk.org/browse/JDK-8314823) you can see that the problem described is *not* that people are using `createTestJvm` in error. The problem is that they are (or possibly are) using `createJavaProcessBuilder` in error. Thus renaming `createTestJvm` might help a little at most for this specific problem. Renaming `createJavaProcessBuilder` most probably helps *more*. I guess the alternative of forcing the user to make a choice using an enum value will help even more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1708705105 From duke at openjdk.org Wed Sep 6 16:44:15 2023 From: duke at openjdk.org (Qing Xiao) Date: Wed, 6 Sep 2023 16:44:15 GMT Subject: RFR: 8315444: Convert test/jdk/tools to Classfile API [v3] In-Reply-To: References: Message-ID: > `/test/jdk/tools/lib/tests/JImageValidator.java`, tests in `/test/jdk/tools/jlink`, and `/test/jdk/tools/jimage`, `/test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java` use on com.sun.tools.classfile and should be converted to Classfile API. Qing Xiao has updated the pull request incrementally with two additional commits since the last revision: - Change the position of a brace - Remove unnecessary import of `impl` and added stronger verify in JImageValidator.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15529/files - new: https://git.openjdk.org/jdk/pull/15529/files/48b6401c..d7a2bd6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15529&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15529&range=01-02 Stats: 31 lines in 24 files changed: 6 ins; 23 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15529/head:pull/15529 PR: https://git.openjdk.org/jdk/pull/15529 From cjplummer at openjdk.org Wed Sep 6 16:52:42 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 6 Sep 2023 16:52:42 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 16:06:29 GMT, Erik Joelsson wrote: > > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools. > > Do you think I should revert them? I'm not sure. I think you need to consult someone with expertise in this area. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708757719 From mchung at openjdk.org Wed Sep 6 16:53:31 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Sep 2023 16:53:31 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v10] In-Reply-To: References: Message-ID: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` > can be used instead and such stack walker will save the overhead of extracting the method information > and the memory used for the stack walking. > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can create a stack walker instance with `DROP_METHOD_INFO` option: > > > StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(Predicate.not(implClasses::contains)) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Javadoc & specdiff > > https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html > https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > ### Implementation Details > > A `StackWalker` configured with `DROP_METHOD_INFO` option creates `ClassFrameInfo[]` > buffer that is filled by the VM during stack walking. `Sta... Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: - Generify StackFrameInfo to replace duplicated code - replace href with @linkplain ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15370/files - new: https://git.openjdk.org/jdk/pull/15370/files/111661bc..a623b9dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=08-09 Stats: 146 lines in 2 files changed: 22 ins; 97 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From duke at openjdk.org Wed Sep 6 16:54:47 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 16:54:47 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Wed, 6 Sep 2023 16:10:27 GMT, Roger Riggs wrote: > I'd be more comfortable replacing the use of Unsafe with either the ByteArray functions or VarHandles. Using VarHandles will enable future optimizations, whereas Unsafe is a primitive tool and is brittle. I also agree that using VarHandler is better, but using VarHandler in StringLatin1 causes exception, as follows: final class StringLatin1 { private static final VarHandle SHORT = MethodHandles.byteArrayViewVarHandle(short[].class, ByteOrder.LITTLE_ENDIAN); } make images Building target 'images' in configuration 'macosx-aarch64-server-release' Compiling up to 3452 files for java.base Updating support/src.zip Updating images/sec-bin.zip Optimizing the exploded image Error occurred during initialization of VM java.lang.ExceptionInInitializerError at java.lang.invoke.VarHandle.(java.base/VarHandle.java:2246) at java.lang.invoke.VarHandles.byteArrayViewHandle(java.base/VarHandles.java:258) at java.lang.invoke.MethodHandles.byteArrayViewVarHandle(java.base/MethodHandles.java:4553) at java.lang.StringLatin1.(java.base/StringLatin1.java:84) at java.lang.String.equals(java.base/String.java:1863) at java.util.ImmutableCollections$Set12.(java.base/ImmutableCollections.java:797) at java.util.Set.of(java.base/Set.java:487) at jdk.internal.reflect.Reflection.(java.base/Reflection.java:58) at java.security.AccessController.doPrivileged(java.base/AccessController.java:319) at java.lang.reflect.AccessibleObject.(java.base/AccessibleObject.java:524) Caused by: java.lang.NullPointerException at java.lang.invoke.MethodHandleStatics.(java.base/MethodHandleStatics.java:70) at java.lang.invoke.VarHandle.(java.base/VarHandle.java:2246) at java.lang.invoke.VarHandles.byteArrayViewHandle(java.base/VarHandles.java:258) at java.lang.invoke.MethodHandles.byteArrayViewVarHandle(java.base/MethodHandles.java:4553) at java.lang.StringLatin1.(java.base/StringLatin1.java:84) at java.lang.String.equals(java.base/String.java:1863) at java.util.ImmutableCollections$Set12.(java.base/ImmutableCollections.java:797) at java.util.Set.of(java.base/Set.java:487) at jdk.internal.reflect.Reflection.(java.base/Reflection.java:58) at java.security.AccessController.doPrivileged(java.base/AccessController.java:319) at java.lang.reflect.AccessibleObject.(java.base/AccessibleObject.java:524) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1708760741 From mchung at openjdk.org Wed Sep 6 16:56:50 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Sep 2023 16:56:50 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v9] In-Reply-To: References: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> Message-ID: <-IQ8wGpAOQ7BHe2A-anvu-YcxARJWCMUFPdEV4xwj2U=.45bc706a-155b-4185-a6e7-e336e562352b@github.com> On Thu, 31 Aug 2023 23:17:02 GMT, Brent Christian wrote: >> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: >> >> - Merge >> - Remove the new getInstance method taking varargs >> - update mode to be int rather than long >> - update tests >> - Review feedback on javadoc >> - Revised the API change. Add Option::DROP_METHOD_INFO >> - Review feedback from Remi >> - fixup javadoc >> - Review feedback: move JLIA to ClassFrameInfo >> - review feedback and javadoc clean up >> - ... and 19 more: https://git.openjdk.org/jdk/compare/c8acab1d...111661bc > > src/java.base/share/classes/java/lang/StackStreamFactory.java line 657: > >> 655: static final class ClassFrameBuffer extends FrameBuffer { >> 656: final StackWalker walker; >> 657: ClassFrameInfo[] classFrames; // caller class for fast path > > Maybe I missed it, but I don't see any differences between `ClassFramesBuffer` and `StackFrameBuffer` other than the `ClassFrameInfo`/`StackFrameInfo` types. Could a single, generified Buffer class serve for both? Good observation. There is some performance difference when the buffer is created via core reflection vs via bytecode invocation. StackFrameTraverser and LiveStackFrameTraverser can use the generified version. As `getCallerClass` is performance sensitive, need to keep `ClassFrameBuffer`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1317577196 From qamai at openjdk.org Wed Sep 6 16:58:43 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 6 Sep 2023 16:58:43 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Wed, 6 Sep 2023 16:51:51 GMT, ??? wrote: >> I'd be more comfortable replacing the use of Unsafe with either the ByteArray functions or VarHandles. >> Using VarHandles will enable future optimizations, whereas Unsafe is a primitive tool and is brittle. > >> I'd be more comfortable replacing the use of Unsafe with either the ByteArray functions or VarHandles. Using VarHandles will enable future optimizations, whereas Unsafe is a primitive tool and is brittle. > > I also agree that using VarHandler is better, but using VarHandler in StringLatin1 causes exception, as follows: > > > final class StringLatin1 { > private static final VarHandle SHORT = MethodHandles.byteArrayViewVarHandle(short[].class, ByteOrder.LITTLE_ENDIAN); > } > > > > make images > Building target 'images' in configuration 'macosx-aarch64-server-release' > Compiling up to 3452 files for java.base > Updating support/src.zip > Updating images/sec-bin.zip > Optimizing the exploded image > Error occurred during initialization of VM > java.lang.ExceptionInInitializerError > at java.lang.invoke.VarHandle.(java.base/VarHandle.java:2246) > at java.lang.invoke.VarHandles.byteArrayViewHandle(java.base/VarHandles.java:258) > at java.lang.invoke.MethodHandles.byteArrayViewVarHandle(java.base/MethodHandles.java:4553) > at java.lang.StringLatin1.(java.base/StringLatin1.java:84) > at java.lang.String.equals(java.base/String.java:1863) > at java.util.ImmutableCollections$Set12.(java.base/ImmutableCollections.java:797) > at java.util.Set.of(java.base/Set.java:487) > at jdk.internal.reflect.Reflection.(java.base/Reflection.java:58) > at java.security.AccessController.doPrivileged(java.base/AccessController.java:319) > at java.lang.reflect.AccessibleObject.(java.base/AccessibleObject.java:524) > Caused by: java.lang.NullPointerException > at java.lang.invoke.MethodHandleStatics.(java.base/MethodHandleStatics.java:70) > at java.lang.invoke.VarHandle.(java.base/VarHandle.java:2246) > at java.lang.invoke.VarHandles.byteArrayViewHandle(java.base/VarHandles.java:258) > at java.lang.invoke.MethodHandles.byteArrayViewVarHandle(java.base/MethodHandles.java:4553) > at java.lang.StringLatin1.(java.base/StringLatin1.java:84) > at java.lang.String.equals(java.base/String.java:1863) > at java.util.ImmutableCollections$Set12.(java.base/ImmutableCollections.java:797) > at java.util.Set.of(java.base/Set.java:487) > at jdk.internal.reflect.Reflection.(java.base/Reflection.java:58) > at java.security.AccessController.doPrivileged(java.base/AccessController.java:319) > at java.lang.reflect.AccessibleObject.(java.base/AccessibleObject.java:524) @wenshao You can use a holder class that will get initialized only when `StringLatin1::getChars` is called. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1708765640 From duke at openjdk.org Wed Sep 6 16:59:54 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Wed, 6 Sep 2023 16:59:54 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30] In-Reply-To: References: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com> Message-ID: On Wed, 30 Aug 2023 15:10:45 GMT, Srinivas Vamsi Parasa wrote: >>> Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags >> >> Just to add that Sorting.java has short and long run modes. The default when running with jtreg or make run-test is the short run so that it doesn't take too long. It might be useful to try it without -shortrun to give the intrinsic a better work out. > >> @AlanBateman If it helps, the changes made by @vamsi-parasa to DualPivotQuickSort.java don't change the logic as written in Java. They only carve out the functionality into separate Java methods retaining the meaning exactly as before. These Java methods are then optimized through a stub. > > Hi Alan, > > As Sandhya (@sviswa7) mentioned, this PR does not make any logic changes to the DualPivotQuickSort.java. > > The code was refactored to separate out the partitioning logic (dual pivot and single pivot) into separate methods. These methods are being intrinsified using AVX512 to do vectorized partitioning preserving the logic of Java side. Similarly, the methods to sort small arrays (insertionSort/mixedInsertionSort) are being intrinsified as well to use AVX512 sort while preserving the logic on Java side. > > Could you please go through the changes and provide your comments and suggestions? > > Thanks, > Vamsi > Hi Vamsi (@vamsi-parasa)! > > Please see my few questions/suggestions related to method arraySort() and other code. > > **1.** If size < MIN_FAST_SMALL_ARRAY_SORT_SIZE (=16), you don't go into intrinsic arraySort(), method mixedInsertionSort is invoked instead. > > `if (size < MAX_MIXED_INSERTION_SORT_SIZE + bits && (bits & 1) > 0) {` ` int last = high - 3 * ((size >> 5) << 3);` ` if (size < MIN_FAST_SMALL_ARRAY_SORT_SIZE) mixedInsertionSort(a, low, last , high);` ` else arraySort(int.class, a, baseOffset, low, high, last);` ` return;` `}` > > Is Java mixedInsertionSort actually faster than intrinsic arraySort() on small (< 16) arrays? What if you try to invoke arraySort() on all small arrays and don't use constant MIN_FAST_SMALL_ARRAY_SORT_SIZE at all? Like this: > > `if (size < MAX_MIXED_INSERTION_SORT_SIZE + bits && (bits & 1) > 0) {` ` int last = high - 3 * ((size >> 5) << 3);` ` arraySort(int.class, a, baseOffset, low, high, last);` ` return;` `}` > > Could you please check and benchmark it? > > **2.** On the next step you apply the same approach when you invoke insertionSort() on the small leftmost part. > > `if (size < MAX_INSERTION_SORT_SIZE) {` ` if (size < MIN_FAST_SMALL_ARRAY_SORT_SIZE) insertionSort(a, low, high);` ` else arraySort(int.class, a, baseOffset, low, high, -1);` ` return;` `}` > > But this invocation happens only once, on the leftmost part only. I think we can invoke Java code and don't go to intrinsic arraySort(). I guess we will not have profit with intrinsic method here. See: > > `if (size < MAX_INSERTION_SORT_SIZE) {` ` insertionSort(a, low, high);` ` return;` `}` > > Could you please try this case without intrinsic and benchmark it? > > **3.** You introduce constant int baseOffset = Unsafe.ARRAY_INT_BASE_OFFSET inside the loop. What if we pass the constant directly? For example: > > `arraySort(int.class, a, Unsafe.ARRAY_INT_BASE_OFFSET, low, high, last);` > > **3.A** The first parameter of arraySort() is elemType (int.class, long,class etc.) The second parameter base offset depends on this elem type. For example, if elemType is int.class, base offset will be Unsafe.ARRAY_INT_BASE_OFFSET. Can we eliminate base offset here and set up value inside intrinsic? > > **4.** You define 'int[] pivotIndices;' at the beginning of the loop, but the indices will be used later (or not used at all). My proposal to declare pivotIndices in if-then-else, see: > > `int[] pivotIndices = new int[] {e1, e5};` > > **5.** Method arrayPartition has argument isDualPivot, I think we can avoid it. If isDualPivot is true, pivot indices are different. If indices are equal, it means single pivot partitioning. So, changes are: > > `private static void arrayPartition(Class elemType, Object array, long offset, int low, int high, int[] pivotIndices) {` ` if (pivotIndices[0] == pivotIndices[1]) partitionSinglePivot(array, low, high, pivotIndices);` ` else partitionDualPivot(array, low, high, pivotIndices);` `}` > > **6.** Please add brackets for 'then' and 'else' statements according to common Java style: > > `if (pivotIndices[0] == pivotIndices[1]) {` ` partitionSinglePivot(array, low, high, pivotIndices);` `} else {` ` partitionDualPivot(array, low, high, pivotIndices);` `};` > > Thank you, Vladimir Hello Vladimir (@iaroslavski) Thank you for the suggestions! Regarding suggestions (1) and (2): will soon provide the performance data when using small arrays (<= 16) with and without the intrinsic. Regarding the code refactoring suggestions in (3) to (6): I am currently working on code refactoring on both the Java and intrinsic side. Your suggestions will be incorporated in the refactoring. Will inform you after the new changes have been pushed to github. Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1708766999 From mandy.chung at oracle.com Wed Sep 6 17:13:45 2023 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 6 Sep 2023 10:13:45 -0700 Subject: Question on why sun.management MBeans are not exported? In-Reply-To: References: <1535aa6e-6865-d885-3930-df7f9ebcb4b4@oracle.com> Message-ID: On 9/6/23 8:17 AM, Volker Simonis wrote: > Anyway, if you classify the MBeans in "sun.management" as non-critical > internal APIs (with respect to JEP 260) but without any "internal" > usage, than we should really remove them, right, because an internal > API without any internal usage doesn't make any sense? We added these HotSpot internal MBeans in JDK 5 to expose the internal metrics.? Most of these internal metrics are exposed via jstat tool too.?? We didn't receive much feedback regarding these HotSpot internal MBeans.??? Removing them is fine and good cleanup effort. Mandy > > I'll then try to come up with a proposal to port some of the more > useful MBeans functionality in "sun.management" to > "com.sun.management". > > Thank you and best regards, > Volker > >> >>> : >>> >>> So to cut a long story short, I see several options: >>> >>> 1. Publicly export sun.management and restore the JDK 8 (or pre JDK >>> 16) behavior. This would certainly require some polishing (e.g. some >>> of the corresponding JVM functionality has already been removed [1]) >>> but I think it could still be quite useful. >>> 2. Port the useful functionality from the "sun.management" MBeans to >>> corresponding "com.sun.management" MBeans and remove the >>> "sun.management" MBeans. >>> 3. Remove the "sun.management" MBeans without substitution. >>> >>> What do you think? >> If there are JDK-specific or HotSpot VM specific features where there is >> a compelling case for a management interface then com.sun.management is >> good place to prototype new APIs. You may already be familiar with >> com.sun.management.HotSpotDiagnosticMBean. >> >> -Alan From duke at openjdk.org Wed Sep 6 17:16:45 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 17:16:45 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Tue, 5 Sep 2023 00:10:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright date info In the test of Integers.toStringBig, using ByteArrayLittleEndian is about 5% slower than using Unsafe. * Integer.getChars static int getChars(int i, int index, byte[] buf) { // Used by trusted callers. Assumes all necessary bounds checks have been done by the caller. int q, r; int charPos = index; boolean negative = i < 0; if (!negative) { i = -i; } // Generate two digits per iteration while (i <= -100) { q = i / 100; r = (q * 100) - i; i = q; charPos -= 2; assert charPos >= 0 && charPos < buf.length : "Trusted caller missed bounds check"; ByteArrayLittleEndian.setShort(buf, charPos, PACKED_DIGITS[r]); } // We know there are at most two digits left at this point. if (i < -9) { charPos -= 2; assert charPos >= 0 && charPos < buf.length : "Trusted caller missed bounds check"; ByteArrayLittleEndian.setShort(buf, charPos, PACKED_DIGITS[-i]); } else { buf[--charPos] = (byte)('0' - i); } if (negative) { buf[--charPos] = (byte)'-'; } return charPos; } * jmh test make test TEST="micro:java.lang.Integers.toStringBig" * result -Benchmark (size) Mode Cnt Score Error Units (use Unsafe) -Integers.toStringBig 500 avgt 15 5.152 ? 0.052 us/op +Benchmark (size) Mode Cnt Score Error Units (use ByteArrayLittleEndian) +Integers.toStringBig 500 avgt 15 5.386 ? 0.020 us/op (slower 4.5%) If you must not use Unsafe, I will replace it with ByteArrayLittleEndian ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1708790375 From alanb at openjdk.org Wed Sep 6 17:45:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Sep 2023 17:45:41 GMT Subject: RFR: 8267174: Many test files have the wrong Copyright header In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote: > > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools. > > Do you think I should revert them? They are test classes now. If someone does want to copy them into their own repo then I assume they can take it from an old repo, maybe from when the "hat" tool existed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708828207 From Alan.Bateman at oracle.com Wed Sep 6 17:50:42 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Sep 2023 18:50:42 +0100 Subject: Question on why sun.management MBeans are not exported? In-Reply-To: References: <1535aa6e-6865-d885-3930-df7f9ebcb4b4@oracle.com> Message-ID: <70186c9a-79ba-e63d-7ed9-1033dece525c@oracle.com> On 06/09/2023 16:17, Volker Simonis wrote: > : > I'm familiar with JEP 260. But wouldn't you agree that an > "encapsulated" monitoring API is an oxymoron? A monitoring API is by > design intended for external usage and completely useless to the > platform itself. There's no single usage of the "sun.management" > MBeans in the JDK itself (except for jconsole where the encapsulation > broke it). My assumption is that the corresponding MBeans in > "sun.management" are there for historic reasons (added in JDK 1.5) and > would have made much more sense in "com.sun.management" package. But I > doubt that they can be classified in the "internal implementation > details of the JDK and never intended for external use? category of > JEP 260. It's left over from experiments on exposing some internal metrics, I think during JDK 5. It's code that should probably have been removed a long time ago. -Alan From jlu at openjdk.org Wed Sep 6 18:05:52 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 6 Sep 2023 18:05:52 GMT Subject: Integrated: 8314604: j.text.DecimalFormat behavior regarding patterns is not clear In-Reply-To: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com> References: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com> Message-ID: On Fri, 18 Aug 2023 21:28:34 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314607) which clarifies the behavior of patterns in regards to the max integer digits in j.text.DecimalFormat. > > The current specification (of `applyPattern`) states that patterns do not set the value of max integer digits. This is incorrect, these methods/constructors do set a value for the max integer digits. If the pattern is in scientific notation, the max integer digits value is derived from the pattern. Otherwise, the pattern is ignored, and the limit is set to `Integer.MAX_VALUE`. > > See below, > > DecimalFormat df = new DecimalFormat(); > df.applyPattern("000.000E0"); > df.getMaximumIntegerDigits(); // ==> 3 > df.applyPattern("000.000"); > df.getMaximumIntegerDigits(); // ==> 2147483647 > > DecimalFormat df = new DecimalFormat("000.000"); > df.getMaximumIntegerDigits(); // ==> 2147483647 > DecimalFormat df = new DecimalFormat("000.000E0"); > df.getMaximumIntegerDigits(); // ==> 3 > > > Method descriptions should be fixed, and the relevant constructors need to mention the behavior as well. This pull request has now been integrated. Changeset: 86a18f5e Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/86a18f5e2e0825dddb77656b2f43f64684f1464c Stats: 22 lines in 1 file changed: 13 ins; 2 del; 7 mod 8314604: j.text.DecimalFormat behavior regarding patterns is not clear Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/15349 From rriggs at openjdk.org Wed Sep 6 18:07:45 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Sep 2023 18:07:45 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Tue, 5 Sep 2023 00:10:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright date info The bulk of the improvement comes from the algorithmic change; using ByteArrayLittleEndian is more robust. Thanks for the performance numbers, though hard to compare with the originals. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1708855452 From mdoerr at openjdk.org Wed Sep 6 18:14:39 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 6 Sep 2023 18:14:39 GMT Subject: RFR: JDK-8315751: RandomTestBsi1999 fails often with timeouts on Linux ppc64le In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 14:47:20 GMT, Matthias Baesken wrote: > The test RandomTestBsi1999 fails often with timeouts on Linux ppc64le; even when it succeeds the test takes a lot of time and is close to timing out. Probably we should increase the timeout value for this test. LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15594#pullrequestreview-1613945983 From mchung at openjdk.org Wed Sep 6 18:41:54 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Sep 2023 18:41:54 GMT Subject: RFR: 8315810: Reimplement ReflectionFactory::newConstructorForSerialization with method handles Message-ID: This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles. This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization. This change will allow such VM hack to be removed. A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue. ------------- Commit messages: - Reimplement ReflectionFactory::newConstructorForSerialization with method handle Changes: https://git.openjdk.org/jdk/pull/15600/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15600&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315810 Stats: 162 lines in 10 files changed: 122 ins; 11 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/15600.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15600/head:pull/15600 PR: https://git.openjdk.org/jdk/pull/15600 From redestad at openjdk.org Wed Sep 6 19:19:48 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 6 Sep 2023 19:19:48 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v20] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Tue, 5 Sep 2023 00:10:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > update copyright date info Assuming this is the M1 numbers we're still looking at a ~120% improvement. And if there's some systemic overhead to using `ByteArrayLittleEndian` compared to `Unsafe` then that's something we might improve over time. Rewiring this to use `ByteArrayLittleEndian` may be the way to go for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1708950163 From redestad at openjdk.org Wed Sep 6 19:26:39 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 6 Sep 2023 19:26:39 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: <-W8u-JpaBk6-YzEGDbun13rl2lvK0m2Pxq_XLAZRSEs=.1d1a7c04-ef8f-4383-95b2-13907e725ae8@github.com> References: <-W8u-JpaBk6-YzEGDbun13rl2lvK0m2Pxq_XLAZRSEs=.1d1a7c04-ef8f-4383-95b2-13907e725ae8@github.com> Message-ID: On Wed, 6 Sep 2023 16:10:23 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/util/HexFormat.java line 644: >> >>> 642: return (char)('a' - 10 + value); >>> 643: } >>> 644: return (char)('A' - 10 + value); >> >> Not sure if this would adversely impact performance, but what about factoring out these lines in a private method? They are repeated in `toHighHexDigit`. > > Surprisingly this does carry some cost in the microbenchmarks on my M1. Might be noise, but it seems rather consistent so I'll need to investigate. This: diff --git a/src/java.base/share/classes/java/util/HexFormat.java b/src/java.base/share/classes/java/util/HexFormat.java index 107c362cbc2..177548c03f7 100644 --- a/src/java.base/share/classes/java/util/HexFormat.java +++ b/src/java.base/share/classes/java/util/HexFormat.java @@ -634,14 +634,7 @@ private static String escapeNL(String string) { * @return the hexadecimal character for the low 4 bits {@code 0-3} of the value */ public char toLowHexDigit(int value) { - value = value & 0xf; - if (value < 10) { - return (char)('0' + value); - } - if (digitCase == Case.LOWERCASE) { - return (char)('a' - 10 + value); - } - return (char)('A' - 10 + value); + return toHexDigit(value & 0xf); } /** @@ -655,7 +648,10 @@ public char toLowHexDigit(int value) { * @return the hexadecimal character for the bits {@code 4-7} of the value */ public char toHighHexDigit(int value) { - value = (value >> 4) & 0xf; + return toHexDigit((value >> 4) & 0xf); + } + + private char toHexDigit(int value) { if (value < 10) { return (char)('0' + value); } .. clearly increase cost across all micros: Name Cnt Base Error Test Error Unit Diff% HexFormatBench.appenderLower 15 1,046 ? 0,041 1,301 ? 0,017 us/op -24,4% (p = 0,000*) HexFormatBench.appenderLowerCached 15 1,056 ? 0,055 1,175 ? 0,115 us/op -11,3% (p = 0,001*) HexFormatBench.appenderUpper 15 1,059 ? 0,055 1,303 ? 0,012 us/op -23,0% (p = 0,000*) HexFormatBench.appenderUpperCached 15 1,099 ? 0,014 1,451 ? 0,267 us/op -32,0% (p = 0,000*) HexFormatBench.toHexLower 15 0,322 ? 0,002 0,338 ? 0,005 us/op -4,8% (p = 0,000*) HexFormatBench.toHexLowerCached 15 0,324 ? 0,003 0,411 ? 0,005 us/op -27,0% (p = 0,000*) HexFormatBench.toHexUpper 15 0,324 ? 0,003 0,340 ? 0,003 us/op -4,9% (p = 0,000*) HexFormatBench.toHexUpperCached 15 0,322 ? 0,001 0,411 ? 0,004 us/op -27,6% (p = 0,000*) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15591#discussion_r1317728161 From duke at openjdk.org Wed Sep 6 19:27:38 2023 From: duke at openjdk.org (ExE Boss) Date: Wed, 6 Sep 2023 19:27:38 GMT Subject: RFR: 8315810: Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles In-Reply-To: References: Message-ID: <_d6YUyDMVZKDD8_baQuVbb8WcetTE_KhFT3SszJ3qII=.d6baa77d-8c94-47a4-b38b-6f6c2c334295@github.com> On Wed, 6 Sep 2023 18:34:29 GMT, Mandy Chung wrote: > This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles. > > This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization. This change will allow such VM hack to be removed. > > A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue. I expect this change has very low compatibility risk. This system property is undocumented and will be removed in a future release. See?also: [JDK?8307575] ([GH?13853]) [JDK?8307575]: https://bugs.openjdk.org/browse/JDK-8307575 "[JDK?8307575] Migrate the?serialization constructor accessors to?Method?Handles" [GH?13853]: https://github.com/openjdk/jdk/pull/13853 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15600#issuecomment-1708962019 From duke at openjdk.org Wed Sep 6 19:38:48 2023 From: duke at openjdk.org (ExE Boss) Date: Wed, 6 Sep 2023 19:38:48 GMT Subject: RFR: 8315810: Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles In-Reply-To: References: Message-ID: <84u8rtemL7bI1Z6y6NJS24P1UJFU22RFj_MVQkmSi0E=.87423052-ba1b-4e77-b59d-623fb49cab2d@github.com> On Wed, 6 Sep 2023 18:34:29 GMT, Mandy Chung wrote: > This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles. > > This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization. This change will allow such VM hack to be removed. > > A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue. I expect this change has very low compatibility risk. This system property is undocumented and will be removed in a future release. src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 3534: > 3532: * This method is only used to implement the unsupported > 3533: * sun.reflect.ReflectionFactory::newConstructorForSerialization API. > 3534: */ The?following is?probably more?correct: Suggestion: /** * Produces a method handle that is capable of creating instances of the given class * and instantiated by the given constructor. No security manager check. * * This method is used to implement serialization and the unsupported * sun.reflect.ReflectionFactory::newConstructorForSerialization API. */ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1317735916 From mchung at openjdk.org Wed Sep 6 19:49:40 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Sep 2023 19:49:40 GMT Subject: RFR: 8315810: Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles In-Reply-To: <84u8rtemL7bI1Z6y6NJS24P1UJFU22RFj_MVQkmSi0E=.87423052-ba1b-4e77-b59d-623fb49cab2d@github.com> References: <84u8rtemL7bI1Z6y6NJS24P1UJFU22RFj_MVQkmSi0E=.87423052-ba1b-4e77-b59d-623fb49cab2d@github.com> Message-ID: On Wed, 6 Sep 2023 19:31:22 GMT, ExE Boss wrote: >> This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles. >> >> This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization. This change will allow such VM hack to be removed. >> >> A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue. I expect this change has very low compatibility risk. This system property is undocumented and will be removed in a future release. > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 3534: > >> 3532: * This method is only used to implement the unsupported >> 3533: * sun.reflect.ReflectionFactory::newConstructorForSerialization API. >> 3534: */ > > The?following is?probably more?correct: > Suggestion: > > /** > * Produces a method handle that is capable of creating instances of the given class > * and instantiated by the given constructor. No security manager check. > * > * This method is used to implement serialization and the unsupported > * sun.reflect.ReflectionFactory::newConstructorForSerialization API. > */ What are you referring to "to implement serialization"? It's only used by ReflectionFactory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1317750757 From duke at openjdk.org Wed Sep 6 19:53:41 2023 From: duke at openjdk.org (ExE Boss) Date: Wed, 6 Sep 2023 19:53:41 GMT Subject: RFR: 8315810: Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles In-Reply-To: References: <84u8rtemL7bI1Z6y6NJS24P1UJFU22RFj_MVQkmSi0E=.87423052-ba1b-4e77-b59d-623fb49cab2d@github.com> Message-ID: On Wed, 6 Sep 2023 19:47:19 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 3534: >> >>> 3532: * This method is only used to implement the unsupported >>> 3533: * sun.reflect.ReflectionFactory::newConstructorForSerialization API. >>> 3534: */ >> >> The?following is?probably more?correct: >> Suggestion: >> >> /** >> * Produces a method handle that is capable of creating instances of the given class >> * and instantiated by the given constructor. No security manager check. >> * >> * This method is used to implement serialization and the unsupported >> * sun.reflect.ReflectionFactory::newConstructorForSerialization API. >> */ > > What are you referring to "to implement serialization"? It's only used by ReflectionFactory. It?s?called?from the?implementation of?`JavaLangInvokeAccess::serializableConstructor`, which?is?called by?`jdk.internal.reflect.ReflectionFactory::newConstructorForSerialization`, which?is?called by?`java.io.ObjectStreamClass::getSerializableConstructor`: https://github.com/openjdk/jdk/blob/86a18f5e2e0825dddb77656b2f43f64684f1464c/src/java.base/share/classes/java/io/ObjectStreamClass.java#L1444-L1446 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1317753943 From vromero at openjdk.org Wed Sep 6 20:00:51 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 6 Sep 2023 20:00:51 GMT Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v11] In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> References: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> Message-ID: On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona wrote: >> javap uses proprietary com.sun.tools.classfile library to parse class files. >> >> This patch converts javap to use Classfile API. >> >> Please review. >> >> 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 227 commits: > > - Merge branch 'master' into JDK-8294969-javap > - Merge branch 'master' into JDK-8294969-javap > - fixed code printing and ConstantPoolException reporting indoex > - added DydnamicConstantPoolEntry::bootstrapMethodIndex > fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute > - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead > - throwing ConstantPoolException for invalid BSM entry index > - Merge branch 'master' into JDK-8294969-javap > - fixed JavapTask > - Merge branch 'master' into JDK-8294969-javap > - Merge branch 'master' into JDK-8294969-javap > > # Conflicts: > # src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java > - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b src/jdk.jdeps/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java line 134: > 132: private ClassWriter classWriter; > 133: private Map> pcMap; > 134: private CodeAttribute lr; nit: name `lr` doesn't relate much to the type of the field test/langtools/tools/javap/8260403/T8260403.java line 42: > 40: new String[]{"-c", System.getProperty("test.classes") + "/InvalidSignature.class"}, > 41: new PrintWriter(sw)); > 42: System.out.println(sw); is this for debug purpose only? test/langtools/tools/javap/malformed/MalformedTest.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. isn't this test testing the same as: `test/langtools/tools/javap/8260403/T8260403.java`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317756417 PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317759719 PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317761623 From mchung at openjdk.org Wed Sep 6 20:04:39 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Sep 2023 20:04:39 GMT Subject: RFR: 8315810: Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles In-Reply-To: References: <84u8rtemL7bI1Z6y6NJS24P1UJFU22RFj_MVQkmSi0E=.87423052-ba1b-4e77-b59d-623fb49cab2d@github.com> Message-ID: On Wed, 6 Sep 2023 19:51:07 GMT, ExE Boss wrote: >> What are you referring to "to implement serialization"? It's only used by ReflectionFactory. > > It?s?called?from the?implementation of?`JavaLangInvokeAccess::serializableConstructor`, which?is?called by?`jdk.internal.reflect.ReflectionFactory::newConstructorForSerialization`, which?is?called by?`java.io.ObjectStreamClass::getSerializableConstructor`: > https://github.com/openjdk/jdk/blob/86a18f5e2e0825dddb77656b2f43f64684f1464c/src/java.base/share/classes/java/io/ObjectStreamClass.java#L1444-L1446 I see the confusion. `newConstructionForSerialization` is used by serialization, exposed via `sun.reflect.ReflectionFactory`. I may clarify it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1317767729 From mchung at openjdk.org Wed Sep 6 20:17:46 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Sep 2023 20:17:46 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8] In-Reply-To: References: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> Message-ID: On Wed, 30 Aug 2023 22:01:28 GMT, Brent Christian wrote: >> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: >> >> - update mode to be int rather than long >> - update tests >> - Review feedback on javadoc > > src/java.base/share/classes/java/lang/ClassFrameInfo.java line 37: > >> 35: int flags; // updated by VM to set hidden and caller-sensitive bits >> 36: >> 37: ClassFrameInfo(StackWalker walker) { > > The StackFrameInfo constructor has comment. Maybe add one here, too? sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1317783076 From jlu at openjdk.org Wed Sep 6 20:52:10 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 6 Sep 2023 20:52:10 GMT Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for j.text.Format classes [v4] In-Reply-To: References: Message-ID: > 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`). Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - CSR review: Adjust equals wording, improve correctness of hashCode definitions - CSR review: replace implNote with implSpec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15459/files - new: https://git.openjdk.org/jdk/pull/15459/files/e322412c..0b0aeb51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15459&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15459&range=02-03 Stats: 53 lines in 9 files changed: 8 ins; 0 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/15459.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15459/head:pull/15459 PR: https://git.openjdk.org/jdk/pull/15459 From bchristi at openjdk.org Wed Sep 6 21:38:43 2023 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 6 Sep 2023 21:38:43 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v9] In-Reply-To: References: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> Message-ID: On Tue, 5 Sep 2023 17:52:44 GMT, Mandy Chung wrote: >> test/micro/org/openjdk/bench/java/lang/StackWalkBench.java line 64: >> >>> 62: default -> throw new IllegalArgumentException(name); >>> 63: }; >>> 64: } >> >> The previous `WALKER_DEFAULT` would not have retained the Class reference, but the new `default` will? > > Some benchmarks need the Class reference but some do not. For simplicity, use only walkers that retain Class reference so that all benchmarks can run with the default walker. In my mind, a "default" StackWalker (obtained from no-arg`StackWalker.getInstance()`) does not retain the Class instance. I think this will be confusing when the "default" Param value is reported in JMH results. I like running the benchmarks with both sets of StackWalker options, but I think the `default` Param value should be changed to something like, `class+methods`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1317859222 From bpb at openjdk.org Wed Sep 6 21:45:51 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Sep 2023 21:45:51 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths 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. ------------- Commit messages: - 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths Changes: https://git.openjdk.org/jdk/pull/15603/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287843 Stats: 65 lines in 2 files changed: 54 ins; 0 del; 11 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 bpb at openjdk.org Wed Sep 6 21:45:52 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Sep 2023 21:45:52 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 21:38:39 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. No `File` methods aside from `getCanonicalPath` are affected. The existing `GetCanonicalPath` test is expanded to cover these cases and converted to JUnit 5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1709166051 From bpb at openjdk.org Wed Sep 6 21:56:36 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Sep 2023 21:56:36 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 21:40:14 GMT, Brian Burkhalter wrote: > No `File` methods aside from `getCanonicalPath` are affected. That is to say, other than `GetCanonicalFile`, of course. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1709178997 From liach at openjdk.org Wed Sep 6 22:08:38 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 6 Sep 2023 22:08:38 GMT Subject: RFR: 8315810: Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 18:34:29 GMT, Mandy Chung wrote: > This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles. > > This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization. This change will allow such VM hack to be removed. > > A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue. I expect this change has very low compatibility risk. This system property is undocumented and will be removed in a future release. src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 127: > 125: static ConstructorAccessorImpl newSerializableConstructorAccessor(Class decl, Constructor ctor) { > 126: if (!constructorInSuperclass(decl, ctor)) { > 127: throw new UnsupportedOperationException(ctor + " not a superclass of " + decl.getName()); Notice in JShell 20, you could do this: jshell> import sun.reflect.ReflectionFactory; jshell> var rf = ReflectionFactory.getReflectionFactory() jshell> var c = rf.newConstructorForSerialization(String.class, Boolean.class.getConstructor(boolean.class)) jshell> String d = (String) c.newInstance(false) jshell> d.length() which ends up in an NPE for `d.value` is null. This UOE is technically a new behavior that should be mentioned in the CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1317878647 From naoto at openjdk.org Wed Sep 6 22:11:40 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 6 Sep 2023 22:11:40 GMT Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for j.text.Format classes [v4] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 20:52:10 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`). > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - CSR review: Adjust equals wording, improve correctness of hashCode definitions > - CSR review: replace implNote with implSpec src/java.base/share/classes/java/text/CompactNumberFormat.java line 221: > 219: > 220: // Non-transient / non-static fields should be added to hashCode impl > 221: Did you mean `equals()`? `hashCode()` may not have all the non-transient fields. src/java.base/share/classes/java/text/CompactNumberFormat.java line 2384: > 2382: * > 2383: * All fields of this class that are non-transient and non-static are used > 2384: * to calculate the hash code value. Is this `All` correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15459#discussion_r1317879503 PR Review Comment: https://git.openjdk.org/jdk/pull/15459#discussion_r1317880046 From duke at openjdk.org Wed Sep 6 22:22:12 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 22:22:12 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v21] In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: > Optimization for: > Integer.toString > Long.toString > StringBuilder#append(int) > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.Integers.toString*" > make test TEST="micro:java.lang.Longs.toString*" > make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op > -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op > -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) > +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) > +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) > > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op > -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) > +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op > > +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) > > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op > -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op > -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ? 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... ??? has updated the pull request incrementally with one additional commit since the last revision: use ByteArrayLittleEndian ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14699/files - new: https://git.openjdk.org/jdk/pull/14699/files/18904a93..c0f42a7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=19-20 Stats: 60 lines in 2 files changed: 2 ins; 48 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/14699.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699 PR: https://git.openjdk.org/jdk/pull/14699 From mchung at openjdk.org Wed Sep 6 22:41:39 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Sep 2023 22:41:39 GMT Subject: RFR: 8315810: Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 22:05:47 GMT, Chen Liang wrote: >> This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles. >> >> This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization. This change will allow such VM hack to be removed. >> >> A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue. I expect this change has very low compatibility risk. This system property is undocumented and will be removed in a future release. > > src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 127: > >> 125: static ConstructorAccessorImpl newSerializableConstructorAccessor(Class decl, Constructor ctor) { >> 126: if (!constructorInSuperclass(decl, ctor)) { >> 127: throw new UnsupportedOperationException(ctor + " not a superclass of " + decl.getName()); > > Notice in JShell 20, you could do this: > > jshell> import sun.reflect.ReflectionFactory; > jshell> var rf = ReflectionFactory.getReflectionFactory() > jshell> var c = rf.newConstructorForSerialization(String.class, Boolean.class.getConstructor(boolean.class)) > jshell> String d = (String) c.newInstance(false) > jshell> d.length() > > which ends up in an NPE for `d.value` is null. This UOE is technically a new behavior that should be mentioned in the CSR. good catch. will update the CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1317900597 From mchung at openjdk.org Wed Sep 6 22:54:45 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Sep 2023 22:54:45 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v9] In-Reply-To: References: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> Message-ID: <6pJF7vbeCEhPHQcNx9kqyEwR35OI6f8b94hOy1ka1k4=.6aaf275a-fae1-45ad-a6b9-15328999b4f4@github.com> On Wed, 6 Sep 2023 21:35:49 GMT, Brent Christian wrote: >> Some benchmarks need the Class reference but some do not. For simplicity, use only walkers that retain Class reference so that all benchmarks can run with the default walker. > > In my mind, a "default" StackWalker (obtained from no-arg`StackWalker.getInstance()`) does not retain the Class instance. I think this will be confusing when the "default" Param value is reported in JMH results. > > I like running the benchmarks with both sets of StackWalker options, but I think the `default` Param value should be changed to something like, `class+methods`. OK, can rename it. For the benchmarking purpose, it does not matter if it retains the Class instance or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1317907061 From asemenyuk at openjdk.org Wed Sep 6 23:10:39 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 6 Sep 2023 23:10:39 GMT Subject: RFR: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 [v2] In-Reply-To: References: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> Message-ID: On Wed, 6 Sep 2023 07:29:20 GMT, Matthias Baesken wrote: >> on some RHEL Linux 8.X machines , we run into errors in test tools/jpackage/share/RuntimePackageTest.java#id0 , error can be seen below. >> It looks like these errors occur when running the jtreg tests with higher concurrency, I did not see them when running just the single test. >> >> When adding some test output , we see the 2 top install dirs below (1 is expected, not 2) : >> ./test/unpacked-rpm/opt >> ./test/unpacked-rpm/usr >> >> error output : >> >> java.lang.AssertionError: Expected [1]. Actual [2]: Check the package has 1 top installation directories >> at jdk.jpackage.test.TKit.error(TKit.java:273) >> at jdk.jpackage.test.TKit.assertEquals(TKit.java:576) >> at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:705) >> at jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$3(PackageTest.java:635) >> at java.base/java.util.Optional.ifPresent(Optional.java:178) >> at jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:633) >> at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:592) >> at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) >> at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) >> at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) >> at java.base/java.lang.Iterable.forEach(Iterable.java:75) >> at jdk.jpackage.test.PackageTest.lambda$runActions$24(PackageTest.java:381) >> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) >> at jdk.jpackage.test.PackageTest.lambda$runActions$25(PackageTest.java:380) >> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) >> at jdk.jpackage.test.PackageTest.runActions(PackageTest.java:379) >> at jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) >> at RuntimePackageTest.test(RuntimePackageTest.java:83) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) >> at java.base/java.lang.reflect.Method.invoke(Method.java:580) >> at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) >> at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) >> at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) >> at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) >> at java.base/java.util.ArrayList$ArrayListSpl... > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove output from PackageTest.java Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15528#pullrequestreview-1614338653 From naoto at openjdk.org Wed Sep 6 23:14:45 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 6 Sep 2023 23:14:45 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v2] In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 22:17:00 GMT, Justin Lu wrote: >> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern. >> >> `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified. >> >> The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor. >> >> The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html > > Justin Lu 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 and resolve conflicts > - Include Unicode sequence in pattern > - Drop throws tag, that change can go to JDK8314925 > - Clarify ? > - Adjust pattern definition > - Remove leftover comments > - Revert the example changes to focus on the more important changes > - Adjust wording of getter methods > - Init src/java.base/share/classes/java/text/ChoiceFormat.java line 136: > 134: * Limit Relation Format > 135: * Limit: > 136: * {@code String} that can be parsed as a {@code double} / "∞" ({@code U+221E}) / "-∞" (-{@code U+221E}). Could the first choice be more specific? Also, do `SubPattern`s need to be sorted with `Limit`s? src/java.base/share/classes/java/text/ChoiceFormat.java line 152: > 150: * > 151: * System.out.println("Format with -INF : " + fmt.format(Double.NEGATIVE_INFINITY)); > 152: * // ... Commenting out (with ellipsis) would not print the result below src/java.base/share/classes/java/text/ChoiceFormat.java line 343: > 341: > 342: /** > 343: * Constructs this ChoiceFormat with limits and corresponding formats `this` -> `a` src/java.base/share/classes/java/text/ChoiceFormat.java line 398: > 396: > 397: /** > 398: * Get the limits of this ChoiceFormat. @return can be applied src/java.base/share/classes/java/text/ChoiceFormat.java line 407: > 405: > 406: /** > 407: * Get the formats of this ChoiceFormat. Same here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1317914110 PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1317902030 PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1317916239 PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1317917169 PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1317917388 From vromero at openjdk.org Wed Sep 6 23:15:50 2023 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 6 Sep 2023 23:15:50 GMT Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v11] In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> References: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> Message-ID: On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona wrote: >> javap uses proprietary com.sun.tools.classfile library to parse class files. >> >> This patch converts javap to use Classfile API. >> >> Please review. >> >> 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 227 commits: > > - Merge branch 'master' into JDK-8294969-javap > - Merge branch 'master' into JDK-8294969-javap > - fixed code printing and ConstantPoolException reporting indoex > - added DydnamicConstantPoolEntry::bootstrapMethodIndex > fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute > - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead > - throwing ConstantPoolException for invalid BSM entry index > - Merge branch 'master' into JDK-8294969-javap > - fixed JavapTask > - Merge branch 'master' into JDK-8294969-javap > - Merge branch 'master' into JDK-8294969-javap > > # Conflicts: > # src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java > - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b src/jdk.jdeps/share/classes/com/sun/tools/javap/CodeWriter.java line 89: > 87: ++n; // for 'this' > 88: argCount = Integer.toString(n); > 89: } catch (ConstantPoolException e) { nice clean-up src/jdk.jdeps/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java line 46: > 44: * deletion without notice. > 45: */ > 46: public class LocalVariableTableWriter extends InstructionDetailWriter { nit: two spaces between `extends` and `InstructionDetailWriter` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317835882 PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317915971 From duke at openjdk.org Wed Sep 6 23:36:43 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Wed, 6 Sep 2023 23:36:43 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v21] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: <-AbETVyZlcbWDywQaQXSXIaME89Pfc4wsZld47HFxWg=.66268427-1399-48b4-92ad-eac123598b82@github.com> On Wed, 6 Sep 2023 22:22:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > use ByteArrayLittleEndian The performance test results of the latest version (PR Update 20 [c0f42a7c](https://github.com/openjdk/jdk/pull/14699/files/c0f42a7cfcb3783423689bb05c21b3313d2644f6) ) are as follows: ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) * cpu : intel xeon sapphire rapids (x64) -Benchmark (size) Mode Cnt Score Error Units (baseline) -Integers.toStringBig 500 avgt 15 6.800 ? 0.022 us/op -Integers.toStringSmall 500 avgt 15 4.792 ? 0.021 us/op -Integers.toStringTiny 500 avgt 15 3.757 ? 0.081 us/op +Benchmark (size) Mode Cnt Score Error Units (PR Update 20 c0f42a7c) +Integers.toStringBig 500 avgt 15 5.894 ? 0.046 us/op (+15.37%) +Integers.toStringSmall 500 avgt 15 4.027 ? 0.012 us/op (+18.99%) +Integers.toStringTiny 500 avgt 15 3.491 ? 0.090 us/op (+7.61%) -Benchmark (size) Mode Cnt Score Error Units (baseline) -Longs.toStringBig 500 avgt 15 9.213 ? 0.019 us/op -Longs.toStringSmall 500 avgt 15 4.550 ? 0.016 us/op +Benchmark (size) Mode Cnt Score Error Units (PR Update 20 c0f42a7c) +Longs.toStringBig 500 avgt 15 7.507 ? 0.011 us/op (+22.72%) +Longs.toStringSmall 500 avgt 15 3.967 ? 0.021 us/op (+14.69%) -Benchmark Mode Cnt Score Error Units (baseline) -StringBuilders.toStringCharWithInt8 avgt 15 89.187 ? 0.236 ns/op +Benchmark Mode Cnt Score Error Units (PR Update 20 c0f42a7c) +StringBuilders.toStringCharWithInt8 avgt 15 36.125 ? 0.309 ns/op (+146.88%) Finished running test 'micro:java.lang.StringBuilders.toStringCharWithInt8' ## 2. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) * cpu : aliyun yitian 710 (aarch64) -Benchmark (size) Mode Cnt Score Error Units (baseline) -Integers.toStringBig 500 avgt 15 11.649 ? 0.011 us/op -Integers.toStringSmall 500 avgt 15 6.985 ? 0.018 us/op -Integers.toStringTiny 500 avgt 15 5.972 ? 0.013 us/op +Benchmark (size) Mode Cnt Score Error Units (PR Update 20 c0f42a7c) +Integers.toStringBig 500 avgt 15 8.957 ? 0.026 us/op (+30.05%) +Integers.toStringSmall 500 avgt 15 6.136 ? 0.018 us/op (+13.83%) +Integers.toStringTiny 500 avgt 15 5.753 ? 0.026 us/op (+3.80%) -Benchmark (size) Mode Cnt Score Error Units (baseline) -Longs.toStringBig 500 avgt 15 14.568 ? 0.021 us/op -Longs.toStringSmall 500 avgt 15 7.250 ? 0.023 us/op +Benchmark (size) Mode Cnt Score Error Units (PR Update 20 c0f42a7c) +Longs.toStringBig 500 avgt 15 13.401 ? 0.012 us/op (+8.70%) +Longs.toStringSmall 500 avgt 15 6.031 ? 0.018 us/op (+20.21%) -Benchmark Mode Cnt Score Error Units (baseline) -StringBuilders.toStringCharWithInt8 avgt 15 52.484 ? 0.534 ns/op +Benchmark Mode Cnt Score Error Units (PR Update 20 c0f42a7c) +StringBuilders.toStringCharWithInt8 avgt 15 40.410 ? 0.348 ns/op (+29.87%) ## 3. MacBookPro M1 Pro -Benchmark (size) Mode Cnt Score Error Units (baseline) -Integers.toStringBig 500 avgt 15 18.483 ? 2.771 us/op -Integers.toStringSmall 500 avgt 15 4.435 ? 0.067 us/op -Integers.toStringTiny 500 avgt 15 2.382 ? 0.063 us/op +Benchmark (size) Mode Cnt Score Error Units (PR Update 20 c0f42a7c) +Integers.toStringBig 500 avgt 15 5.392 ? 0.016 us/op (+242.78%) +Integers.toStringSmall 500 avgt 15 3.201 ? 0.024 us/op (+38.55%) +Integers.toStringTiny 500 avgt 15 2.141 ? 0.021 us/op (+11.25%) -Benchmark (size) Mode Cnt Score Error Units (baseline) -Longs.toStringBig 500 avgt 15 8.336 ? 0.025 us/op -Longs.toStringSmall 500 avgt 15 4.389 ? 0.018 us/op +Benchmark (size) Mode Cnt Score Error Units (PR Update 20 c0f42a7c) +Longs.toStringBig 500 avgt 15 7.706 ? 0.015 us/op (+8.17%) +Longs.toStringSmall 500 avgt 15 3.094 ? 0.021 us/op (+41.85%) -Benchmark Mode Cnt Score Error Units (baseline) -StringBuilders.toStringCharWithInt8 avgt 15 124.316 ? 61.017 ns/op +Benchmark Mode Cnt Score Error Units (PR Update 20 c0f42a7c) +StringBuilders.toStringCharWithInt8 avgt 15 44.497 ? 29.741 ns/op (+179.38%) ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1709257471 From joehw at openjdk.org Thu Sep 7 04:30:41 2023 From: joehw at openjdk.org (Joe Wang) Date: Thu, 7 Sep 2023 04:30:41 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v14] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:47:01 GMT, Naoto Sato wrote: >> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Incorporating suggested changes Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15130#pullrequestreview-1614557611 From kirk.pepperdine at gmail.com Thu Sep 7 06:27:57 2023 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Wed, 6 Sep 2023 23:27:57 -0700 Subject: Question on why sun.management MBeans are not exported? In-Reply-To: <70186c9a-79ba-e63d-7ed9-1033dece525c@oracle.com> References: <1535aa6e-6865-d885-3930-df7f9ebcb4b4@oracle.com> <70186c9a-79ba-e63d-7ed9-1033dece525c@oracle.com> Message-ID: Hi, It would be a shame to lose these metrics because many of them have been very useful over time and some would be even more useful with some modifications. For example, the CPU breakouts found in GC logs has been incredibly useful as a proxy measure in helping sort out other issues in systems. So much so that I have analytics built specifically around this in my tooling. Kind regards, Kirk Pepperdine > On Sep 6, 2023, at 10:50 AM, Alan Bateman wrote: > > On 06/09/2023 16:17, Volker Simonis wrote: >> : >> I'm familiar with JEP 260. But wouldn't you agree that an >> "encapsulated" monitoring API is an oxymoron? A monitoring API is by >> design intended for external usage and completely useless to the >> platform itself. There's no single usage of the "sun.management" >> MBeans in the JDK itself (except for jconsole where the encapsulation >> broke it). My assumption is that the corresponding MBeans in >> "sun.management" are there for historic reasons (added in JDK 1.5) and >> would have made much more sense in "com.sun.management" package. But I >> doubt that they can be classified in the "internal implementation >> details of the JDK and never intended for external use? category of >> JEP 260. > It's left over from experiments on exposing some internal metrics, I think during JDK 5. It's code that should probably have been removed a long time ago. > > -Alan From alanb at openjdk.org Thu Sep 7 06:48:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Sep 2023 06:48:40 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4] In-Reply-To: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com> References: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com> Message-ID: On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote: > I think it's useful if trying to trace the calls (i.e. set to 0ms). Apparently the security manager was being used for that by some. The SM isn't called once connected so I don't think anyone could have every done that. Yes, you could set the threshold to 0ms to emit event for every read/write but I wonder how useful that would be, maybe I/O stats would be more interesting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1709568576 From duke at openjdk.org Thu Sep 7 07:15:06 2023 From: duke at openjdk.org (Qing Xiao) Date: Thu, 7 Sep 2023 07:15:06 GMT Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests [v3] In-Reply-To: References: Message-ID: > Modified all tests under lib-test/jdk to use JUnit Qing Xiao has updated the pull request incrementally with one additional commit since the last revision: Change test static method to instance method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15131/files - new: https://git.openjdk.org/jdk/pull/15131/files/0e15e752..e520735d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15131&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15131&range=01-02 Stats: 13 lines in 4 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/15131.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15131/head:pull/15131 PR: https://git.openjdk.org/jdk/pull/15131 From mbaesken at openjdk.org Thu Sep 7 07:33:54 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Sep 2023 07:33:54 GMT Subject: RFR: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 [v2] In-Reply-To: References: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> Message-ID: On Wed, 6 Sep 2023 07:29:20 GMT, Matthias Baesken wrote: >> on some RHEL Linux 8.X machines , we run into errors in test tools/jpackage/share/RuntimePackageTest.java#id0 , error can be seen below. >> It looks like these errors occur when running the jtreg tests with higher concurrency, I did not see them when running just the single test. >> >> When adding some test output , we see the 2 top install dirs below (1 is expected, not 2) : >> ./test/unpacked-rpm/opt >> ./test/unpacked-rpm/usr >> >> error output : >> >> java.lang.AssertionError: Expected [1]. Actual [2]: Check the package has 1 top installation directories >> at jdk.jpackage.test.TKit.error(TKit.java:273) >> at jdk.jpackage.test.TKit.assertEquals(TKit.java:576) >> at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:705) >> at jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$3(PackageTest.java:635) >> at java.base/java.util.Optional.ifPresent(Optional.java:178) >> at jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:633) >> at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:592) >> at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) >> at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) >> at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) >> at java.base/java.lang.Iterable.forEach(Iterable.java:75) >> at jdk.jpackage.test.PackageTest.lambda$runActions$24(PackageTest.java:381) >> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) >> at jdk.jpackage.test.PackageTest.lambda$runActions$25(PackageTest.java:380) >> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) >> at jdk.jpackage.test.PackageTest.runActions(PackageTest.java:379) >> at jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) >> at RuntimePackageTest.test(RuntimePackageTest.java:83) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) >> at java.base/java.lang.reflect.Method.invoke(Method.java:580) >> at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) >> at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) >> at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) >> at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) >> at java.base/java.util.ArrayList$ArrayListSpl... > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove output from PackageTest.java Hi Alexey, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15528#issuecomment-1709620631 From mbaesken at openjdk.org Thu Sep 7 07:33:56 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Sep 2023 07:33:56 GMT Subject: Integrated: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 In-Reply-To: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> References: <-zG1ik7k85vgx9QrH_iwRaWDBmdnwJyDzTWmtouDrxY=.be0f9a3a-ec3d-4e06-9b4c-a80e85d9689a@github.com> Message-ID: On Fri, 1 Sep 2023 07:22:12 GMT, Matthias Baesken wrote: > on some RHEL Linux 8.X machines , we run into errors in test tools/jpackage/share/RuntimePackageTest.java#id0 , error can be seen below. > It looks like these errors occur when running the jtreg tests with higher concurrency, I did not see them when running just the single test. > > When adding some test output , we see the 2 top install dirs below (1 is expected, not 2) : > ./test/unpacked-rpm/opt > ./test/unpacked-rpm/usr > > error output : > > java.lang.AssertionError: Expected [1]. Actual [2]: Check the package has 1 top installation directories > at jdk.jpackage.test.TKit.error(TKit.java:273) > at jdk.jpackage.test.TKit.assertEquals(TKit.java:576) > at jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:705) > at jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$3(PackageTest.java:635) > at java.base/java.util.Optional.ifPresent(Optional.java:178) > at jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:633) > at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:592) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) > at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) > at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) > at java.base/java.lang.Iterable.forEach(Iterable.java:75) > at jdk.jpackage.test.PackageTest.lambda$runActions$24(PackageTest.java:381) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.lambda$runActions$25(PackageTest.java:380) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) > at jdk.jpackage.test.PackageTest.runActions(PackageTest.java:379) > at jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) > at RuntimePackageTest.test(RuntimePackageTest.java:83) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) > at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) > at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) > at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) > at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708) > at java.base/jav... This pull request has now been integrated. Changeset: 8107eab3 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/8107eab3c09b3f9fcf1348c3bf1deb7c4ac2fdf3 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8 Reviewed-by: lucy, asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/15528 From mbaesken at openjdk.org Thu Sep 7 07:39:47 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Sep 2023 07:39:47 GMT Subject: RFR: JDK-8315751: RandomTestBsi1999 fails often with timeouts on Linux ppc64le In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 14:47:20 GMT, Matthias Baesken wrote: > The test RandomTestBsi1999 fails often with timeouts on Linux ppc64le; even when it succeeds the test takes a lot of time and is close to timing out. Probably we should increase the timeout value for this test. Hi Martin, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15594#issuecomment-1709628033 From mbaesken at openjdk.org Thu Sep 7 07:39:48 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Sep 2023 07:39:48 GMT Subject: Integrated: JDK-8315751: RandomTestBsi1999 fails often with timeouts on Linux ppc64le In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 14:47:20 GMT, Matthias Baesken wrote: > The test RandomTestBsi1999 fails often with timeouts on Linux ppc64le; even when it succeeds the test takes a lot of time and is close to timing out. Probably we should increase the timeout value for this test. This pull request has now been integrated. Changeset: 9887cd8a Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/9887cd8adc408a71b045b1a4891cc0d5dede7e0e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8315751: RandomTestBsi1999 fails often with timeouts on Linux ppc64le Reviewed-by: mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/15594 From pminborg at openjdk.org Thu Sep 7 07:46:03 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 7 Sep 2023 07:46:03 GMT Subject: RFR: 8314260: Unable to load system libraries on Windows when using a SecurityManager [v4] In-Reply-To: References: Message-ID: > This PR proposes to read the system environment variable "SystemRoot" using a privileged operation so it will work in the event a default SecurityManager is in place. > > As the `SecurityManager` is deprecated for removal, no support methods were added for reading environmental variables. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add privilidged action and restrict grants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15564/files - new: https://git.openjdk.org/jdk/pull/15564/files/0cc7c381..16e74316 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15564&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15564&range=02-03 Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15564.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15564/head:pull/15564 PR: https://git.openjdk.org/jdk/pull/15564 From asotona at openjdk.org Thu Sep 7 08:28:54 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 7 Sep 2023 08:28:54 GMT Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v11] In-Reply-To: References: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> Message-ID: On Wed, 6 Sep 2023 19:55:49 GMT, Vicente Romero wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits: >> >> - Merge branch 'master' into JDK-8294969-javap >> - Merge branch 'master' into JDK-8294969-javap >> - fixed code printing and ConstantPoolException reporting indoex >> - added DydnamicConstantPoolEntry::bootstrapMethodIndex >> fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute >> - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead >> - throwing ConstantPoolException for invalid BSM entry index >> - Merge branch 'master' into JDK-8294969-javap >> - fixed JavapTask >> - Merge branch 'master' into JDK-8294969-javap >> - Merge branch 'master' into JDK-8294969-javap >> >> # Conflicts: >> # src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java >> - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b > > test/langtools/tools/javap/8260403/T8260403.java line 42: > >> 40: new String[]{"-c", System.getProperty("test.classes") + "/InvalidSignature.class"}, >> 41: new PrintWriter(sw)); >> 42: System.out.println(sw); > > is this for debug purpose only? It is the test fix. 8260403 says "javap should be more robust", however to expect zero exit code for invalid class is wrong. It suppose to expect non-zero exit code and fail only on fatal errors or unhandled CP errors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318264327 From asotona at openjdk.org Thu Sep 7 08:34:52 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 7 Sep 2023 08:34:52 GMT Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v11] In-Reply-To: References: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> Message-ID: On Wed, 6 Sep 2023 19:57:19 GMT, Vicente Romero wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits: >> >> - Merge branch 'master' into JDK-8294969-javap >> - Merge branch 'master' into JDK-8294969-javap >> - fixed code printing and ConstantPoolException reporting indoex >> - added DydnamicConstantPoolEntry::bootstrapMethodIndex >> fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute >> - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead >> - throwing ConstantPoolException for invalid BSM entry index >> - Merge branch 'master' into JDK-8294969-javap >> - fixed JavapTask >> - Merge branch 'master' into JDK-8294969-javap >> - Merge branch 'master' into JDK-8294969-javap >> >> # Conflicts: >> # src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java >> - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b > > test/langtools/tools/javap/malformed/MalformedTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. > > isn't this test testing the same as: `test/langtools/tools/javap/8260403/T8260403.java`? The principle of the test is the same, but it tests intentionally different class malformations (on a different level). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318272202 From alanb at openjdk.org Thu Sep 7 08:36:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Sep 2023 08:36:40 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 21:38:39 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. Would it be possible to summarise how this behaves when File just presents this prefix? It would be a weird thing to do but it may come about from usages of getParent or other methods. I think I'm mostly asking if is possible for the method to return the canonical path of the current directory when it should fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1709709146 From asotona at openjdk.org Thu Sep 7 08:38:51 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 7 Sep 2023 08:38:51 GMT Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v11] In-Reply-To: References: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> Message-ID: On Wed, 6 Sep 2023 19:53:12 GMT, Vicente Romero wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits: >> >> - Merge branch 'master' into JDK-8294969-javap >> - Merge branch 'master' into JDK-8294969-javap >> - fixed code printing and ConstantPoolException reporting indoex >> - added DydnamicConstantPoolEntry::bootstrapMethodIndex >> fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute >> - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead >> - throwing ConstantPoolException for invalid BSM entry index >> - Merge branch 'master' into JDK-8294969-javap >> - fixed JavapTask >> - Merge branch 'master' into JDK-8294969-javap >> - Merge branch 'master' into JDK-8294969-javap >> >> # Conflicts: >> # src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java >> - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b > > src/jdk.jdeps/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java line 134: > >> 132: private ClassWriter classWriter; >> 133: private Map> pcMap; >> 134: private CodeAttribute lr; > > nit: name `lr` doesn't relate much to the type of the field Right, `lr` historically came from label resolver, I'll fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318277017 From duke at openjdk.org Thu Sep 7 08:48:44 2023 From: duke at openjdk.org (Viktor Klang) Date: Thu, 7 Sep 2023 08:48:44 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v25] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:07:10 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: > > Allow ThreadGroup access in tck tests test/jdk/java/util/concurrent/tck/JSR166TestCase.java line 1687: > 1685: thread.join(timeoutMillis); > 1686: break; > 1687: } catch (InterruptedException ignore) { @DougLea Shouldn't this deduct the wait-time for the next join if it gets interrupted? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1318289951 From aturbanov at openjdk.org Thu Sep 7 08:52:40 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 7 Sep 2023 08:52:40 GMT Subject: RFR: 8315810: Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 18:34:29 GMT, Mandy Chung wrote: > This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles. > > This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization. This change will allow such VM hack to be removed. > > A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue. I expect this change has very low compatibility risk. This system property is undocumented and will be removed in a future release. src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java line 198: > 196: if (!declaringClass.isAssignableFrom(o.getClass())) { > 197: throw new IllegalArgumentException("object of type " + o.getClass().getName() > 198: + " is not an instance of " + declaringClass.getName()); Suggestion: + " is not an instance of " + declaringClass.getName()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1318295076 From lucy at openjdk.org Thu Sep 7 09:13:48 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 7 Sep 2023 09:13:48 GMT Subject: RFR: JDK-8315751: RandomTestBsi1999 fails often with timeouts on Linux ppc64le In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 14:47:20 GMT, Matthias Baesken wrote: > The test RandomTestBsi1999 fails often with timeouts on Linux ppc64le; even when it succeeds the test takes a lot of time and is close to timing out. Probably we should increase the timeout value for this test. Looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/15594#pullrequestreview-1614961811 From asotona at openjdk.org Thu Sep 7 09:19:23 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 7 Sep 2023 09:19:23 GMT Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v12] In-Reply-To: References: Message-ID: <-LczHX74gCWta8AmyezcptxGkMWzMbA8ENqE1DVTvAM=.7f9563b6-fc53-4b6e-a417-a9a9d98c5e34@github.com> > javap uses proprietary com.sun.tools.classfile library to parse class files. > > This patch converts javap to use Classfile API. > > Please review. > > 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 229 commits: - minor patches - Merge branch 'master' into JDK-8294969 - Merge branch 'master' into JDK-8294969-javap - Merge branch 'master' into JDK-8294969-javap - fixed code printing and ConstantPoolException reporting indoex - added DydnamicConstantPoolEntry::bootstrapMethodIndex fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead - throwing ConstantPoolException for invalid BSM entry index - Merge branch 'master' into JDK-8294969-javap - fixed JavapTask - ... and 219 more: https://git.openjdk.org/jdk/compare/9887cd8a...697079f7 ------------- Changes: https://git.openjdk.org/jdk/pull/11411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=11 Stats: 3831 lines in 29 files changed: 1001 ins; 1701 del; 1129 mod Patch: https://git.openjdk.org/jdk/pull/11411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411 PR: https://git.openjdk.org/jdk/pull/11411 From myano at openjdk.org Thu Sep 7 09:21:39 2023 From: myano at openjdk.org (Masanori Yano) Date: Thu, 7 Sep 2023 09:21:39 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? I agree that Runtime.halt() should be terminated immediately. However, I don't think this logging feature is for normal use, but for troubleshooting when we can't find where Runtime.halt() is called. So I don't think it will prevent Runtime.halt() from exiting immediately in normal operation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1709793801 From redestad at openjdk.org Thu Sep 7 10:38:43 2023 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 7 Sep 2023 10:38:43 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v21] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Wed, 6 Sep 2023 22:22:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > use ByteArrayLittleEndian Using `ByteArrayLittleEndian` cleaned up the code nicely. The overhead compared to `Unsafe` doesn't seem too concerning (maybe even some wins?) ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14699#pullrequestreview-1615137576 From jvernee at openjdk.org Thu Sep 7 11:39:30 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 7 Sep 2023 11:39:30 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v15] 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 two additional commits since the last revision: - add name of SysV ABI - Fix javadoc issues in MemorySegment::copy Reviewed-by: jvernee ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/52df58f5..a48a77bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=13-14 Stats: 10 lines in 2 files changed: 3 ins; 0 del; 7 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 Thu Sep 7 11:39:32 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 7 Sep 2023 11:39:32 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v10] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 16:03:40 GMT, Paul Sandoz wrote: >> [This SO question](https://stackoverflow.com/a/40348010) points to a gitlab repo that seems to have the latest version: https://gitlab.com/x86-psABIs/x86-64-ABI But, I'm not sure how stable that is, or if that's an authoritative source. >> >> Alternatively, we could refer to the name only: "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (or "x86-64 psABI") Then people can google for themselves and find it. > > Yeah, its hard to find the official and latest version. Referring to the full title will help. I've added the name now: https://github.com/openjdk/jdk/pull/15103/commits/a48a77bcdadda65a81ad30abf00e6da46a56b933 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1318472039 From jvernee at openjdk.org Thu Sep 7 11:48:40 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 7 Sep 2023 11:48:40 GMT Subject: RFR: 8314260: Unable to load system libraries on Windows when using a SecurityManager [v4] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 07:46:03 GMT, Per Minborg wrote: >> This PR proposes to read the system environment variable "SystemRoot" using a privileged operation so it will work in the event a default SecurityManager is in place. >> >> As the `SecurityManager` is deprecated for removal, no support methods were added for reading environmental variables. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add privilidged action and restrict grants Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15564#pullrequestreview-1615246090 From pminborg at openjdk.org Thu Sep 7 11:55:55 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 7 Sep 2023 11:55:55 GMT Subject: Integrated: 8314260: Unable to load system libraries on Windows when using a SecurityManager In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 08:52:50 GMT, Per Minborg wrote: > This PR proposes to read the system environment variable "SystemRoot" using a privileged operation so it will work in the event a default SecurityManager is in place. > > As the `SecurityManager` is deprecated for removal, no support methods were added for reading environmental variables. This pull request has now been integrated. Changeset: b408a82f Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/b408a82f9b4ce4441f49d745034ef923a880778f Stats: 26 lines in 3 files changed: 24 ins; 0 del; 2 mod 8314260: Unable to load system libraries on Windows when using a SecurityManager Co-authored-by: Jorn Vernee Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/15564 From duke at openjdk.org Thu Sep 7 11:56:45 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Thu, 7 Sep 2023 11:56:45 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v21] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Wed, 6 Sep 2023 22:22:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > use ByteArrayLittleEndian Can it be merged now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1710017528 From pminborg at openjdk.org Thu Sep 7 11:56:53 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 7 Sep 2023 11:56:53 GMT Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes Message-ID: This PR proposes to slightly improve some iterators of `AbstractMap`: * Code reuse * A field declared `final` * Add missing `@Override` annotations ------------- Commit messages: - Improve AbstractMap anonymous Iterator classes Changes: https://git.openjdk.org/jdk/pull/15615/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15615&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315850 Stats: 76 lines in 1 file changed: 44 ins; 28 del; 4 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 shade at openjdk.org Thu Sep 7 12:06:43 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Sep 2023 12:06:43 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 In-Reply-To: References: Message-ID: <-ADTwztAvyuRlGL3nYvS9pUyapIVCwjWT5Zp6xadkJQ=.9a62cd4b-bb7a-4521-8550-4513f70a17c0@github.com> On Mon, 4 Sep 2023 19:54:46 GMT, Martin Doerr wrote: >> Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 164: > >> 162: public static boolean isPPC() { >> 163: return PlatformProps.TARGET_ARCH_IS_PPC; >> 164: } > > Maybe `isPPC32()` would be a better name (also `PPC32` above). Note that hotspot uses `PPC` for all PPC platforms and has the more specific macros `PPC32` and `PPC64`. Yeah, we can technically change to `PPC32`. But the current thing follows what build system uses as `OPENJDK_TARGET_CPU` (`ppc`) and what would be used as `os.arch` because of that. So, choosing which way to deviate: towards build-system/java-props or towards hotspot macros, I think what current PR does is the lesser evil. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15556#discussion_r1318502898 From asotona at openjdk.org Thu Sep 7 12:08:41 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 7 Sep 2023 12:08:41 GMT Subject: RFR: 8315444: Convert test/jdk/tools to Classfile API [v3] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 16:44:15 GMT, Qing Xiao wrote: >> `/test/jdk/tools/lib/tests/JImageValidator.java`, tests in `/test/jdk/tools/jlink`, and `/test/jdk/tools/jimage`, `/test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java` use on com.sun.tools.classfile and should be converted to Classfile API. > > Qing Xiao has updated the pull request incrementally with two additional commits since the last revision: > > - Change the position of a brace > - Remove unnecessary import of `impl` and added stronger verify in JImageValidator.java Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15529#pullrequestreview-1615275932 From forax at openjdk.org Thu Sep 7 12:27:38 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 7 Sep 2023 12:27:38 GMT Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 11:48:51 GMT, Per Minborg wrote: > This PR proposes to slightly improve some iterators of `AbstractMap`: > > * Code reuse > * A field declared `final` > * Add missing `@Override` annotations Hello, In Java, sharing code may have a runtime cost (or not) depending on the shape of the code, because the VM may have to speculate on the class of some value at runtime. Here, in hasNext() and remove(), the VM has to find the class of the field 'i' at runtime. Iterators are performance sentive (they are used in for loop) and for that they need the escape analysis to work. If the iterator code is polymorphic, so part of the code may be unknown so the escape analysis will consider that the iterator escape. So usually, it's a good practice to not share the iterator code. Also the field should be package private (or even maybe private) but not protected. Protected is very rare in Java because usually classes that share implementation details are in the same package (or in the same nestmate nest). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15615#issuecomment-1710058719 From mdoerr at openjdk.org Thu Sep 7 12:47:39 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 7 Sep 2023 12:47:39 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 In-Reply-To: <-ADTwztAvyuRlGL3nYvS9pUyapIVCwjWT5Zp6xadkJQ=.9a62cd4b-bb7a-4521-8550-4513f70a17c0@github.com> References: <-ADTwztAvyuRlGL3nYvS9pUyapIVCwjWT5Zp6xadkJQ=.9a62cd4b-bb7a-4521-8550-4513f70a17c0@github.com> Message-ID: <8X8eYI2wt0ZL_2bpai1gnC5OipIZnQQ9wjupZP-AHVo=.ce05e1c4-528c-4ed0-9b33-cf373abe1528@github.com> On Thu, 7 Sep 2023 12:02:02 GMT, Aleksey Shipilev wrote: >> src/java.base/share/classes/jdk/internal/util/Architecture.java line 164: >> >>> 162: public static boolean isPPC() { >>> 163: return PlatformProps.TARGET_ARCH_IS_PPC; >>> 164: } >> >> Maybe `isPPC32()` would be a better name (also `PPC32` above). Note that hotspot uses `PPC` for all PPC platforms and has the more specific macros `PPC32` and `PPC64`. > > Yeah, we can technically change to `PPC32`. But the current thing follows what build system uses as `OPENJDK_TARGET_CPU` (`ppc`) and what would be used as `os.arch` because of that. So, choosing which way to deviate: towards build-system/java-props or towards hotspot macros, I think what current PR does is the lesser evil. One might expect `isPPC()` to return true on PPC64 because it technically is. This is the only drawback I see. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15556#discussion_r1318550667 From jvernee at openjdk.org Thu Sep 7 13:07:50 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 7 Sep 2023 13:07:50 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v16] 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: Add support for sliced allocation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/a48a77bc..55296527 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=14-15 Stats: 539 lines in 9 files changed: 413 ins; 56 del; 70 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 Thu Sep 7 13:08:15 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 7 Sep 2023 13:08:15 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v15] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 11:39:30 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 two additional commits since the last revision: > > - add name of SysV ABI > - Fix javadoc issues in MemorySegment::copy > > Reviewed-by: jvernee After discussing with Maurizio, I've added one more non-trivial change to this patch, brought over from the panama-foreign repo. This adds a new `SegmentAllocator::allocateFrom` overload which accepts a MemorySegment as an initializer. See the original PR: https://github.com/openjdk/panama-foreign/pull/878 The commit I've added also includes the changes from https://github.com/openjdk/panama-foreign/pull/855 which were required by the first patch. I had to massage the code a bit since the javadoc in the mainline slightly deviates from the one in the panama-foreign repo. Please take a look at the changes here: https://github.com/openjdk/jdk/pull/15103/commits/55296527a029b80dd78a7d1aecb429e793d7d32e ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1710117041 From shade at openjdk.org Thu Sep 7 13:51:31 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Sep 2023 13:51:31 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v2] In-Reply-To: References: Message-ID: > Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Switch to PPC32 - Merge branch 'master' into JDK-8315578-ppc-builds - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15556/files - new: https://git.openjdk.org/jdk/pull/15556/files/218991df..d829d243 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15556&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15556&range=00-01 Stats: 9123 lines in 245 files changed: 7533 ins; 1023 del; 567 mod Patch: https://git.openjdk.org/jdk/pull/15556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15556/head:pull/15556 PR: https://git.openjdk.org/jdk/pull/15556 From shade at openjdk.org Thu Sep 7 13:51:33 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Sep 2023 13:51:33 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v2] In-Reply-To: <8X8eYI2wt0ZL_2bpai1gnC5OipIZnQQ9wjupZP-AHVo=.ce05e1c4-528c-4ed0-9b33-cf373abe1528@github.com> References: <-ADTwztAvyuRlGL3nYvS9pUyapIVCwjWT5Zp6xadkJQ=.9a62cd4b-bb7a-4521-8550-4513f70a17c0@github.com> <8X8eYI2wt0ZL_2bpai1gnC5OipIZnQQ9wjupZP-AHVo=.ce05e1c4-528c-4ed0-9b33-cf373abe1528@github.com> Message-ID: On Thu, 7 Sep 2023 12:45:14 GMT, Martin Doerr wrote: >> Yeah, we can technically change to `PPC32`. But the current thing follows what build system uses as `OPENJDK_TARGET_CPU` (`ppc`) and what would be used as `os.arch` because of that. So, choosing which way to deviate: towards build-system/java-props or towards hotspot macros, I think what current PR does is the lesser evil. > > One might expect `isPPC()` to return true on PPC64 because it technically is. This is the only drawback I see. I don't have a strong opinion here, so if you want PPC32, you got it in new commit :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15556#discussion_r1318636285 From mdoerr at openjdk.org Thu Sep 7 13:57:42 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 7 Sep 2023 13:57:42 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:51:31 GMT, Aleksey Shipilev wrote: >> Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Switch to PPC32 > - Merge branch 'master' into JDK-8315578-ppc-builds > - Fix Thanks! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15556#pullrequestreview-1615501484 From mdoerr at openjdk.org Thu Sep 7 13:57:43 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 7 Sep 2023 13:57:43 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v2] In-Reply-To: References: <-ADTwztAvyuRlGL3nYvS9pUyapIVCwjWT5Zp6xadkJQ=.9a62cd4b-bb7a-4521-8550-4513f70a17c0@github.com> <8X8eYI2wt0ZL_2bpai1gnC5OipIZnQQ9wjupZP-AHVo=.ce05e1c4-528c-4ed0-9b33-cf373abe1528@github.com> Message-ID: On Thu, 7 Sep 2023 13:45:50 GMT, Aleksey Shipilev wrote: >> One might expect `isPPC()` to return true on PPC64 because it technically is. This is the only drawback I see. > > I don't have a strong opinion here, so if you want PPC32, you got it in new commit :) Yeah, at least for the `isPPC32()` method. I think a Java API should minimize risk of confusion and misunderstandings, not reflect the design of the build system. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15556#discussion_r1318646086 From duke at openjdk.org Thu Sep 7 14:02:54 2023 From: duke at openjdk.org (Soumadipta Roy) Date: Thu, 7 Sep 2023 14:02:54 GMT Subject: RFR: 8315683: Parallelize java/util/concurrent/tck/JSR166TestCase.java Message-ID: This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations: before : make test CONF=macosx-aarch64-server-fastdebug 200.64s user 20.94s system 204% cpu 1:48.47 total fully parallel : make test CONF=macosx-aarch64-server-fastdebug 308.84s user 23.75s system 479% cpu 1:09.42 total default-details-tck : make test CONF=macosx-aarch64-server-fastdebug 244.69s user 22.03s system 314% cpu 1:24.94 total default-fjp_details-tck : make test CONF=macosx-aarch64-server-fastdebug 260.12s user 24.47s system 404% cpu 1:10.31 total Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination. ------------- Commit messages: - 8315683: Parallelize java/util/concurrent/tck/JSR166TestCase.java Changes: https://git.openjdk.org/jdk/pull/15619/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15619&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315683 Stats: 19 lines in 1 file changed: 15 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15619/head:pull/15619 PR: https://git.openjdk.org/jdk/pull/15619 From rriggs at openjdk.org Thu Sep 7 14:09:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 7 Sep 2023 14:09:43 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:51:31 GMT, Aleksey Shipilev wrote: >> Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Switch to PPC32 > - Merge branch 'master' into JDK-8315578-ppc-builds > - Fix src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 62: > 60: static final boolean TARGET_ARCH_IS_LOONGARCH64 = "@@OPENJDK_TARGET_CPU@@" == "loongarch64"; > 61: static final boolean TARGET_ARCH_IS_S390 = "@@OPENJDK_TARGET_CPU@@" == "s390"; > 62: static final boolean TARGET_ARCH_IS_PPC32 = "@@OPENJDK_TARGET_CPU@@" == "ppc"; The list is getting longer. I'd suggest/request that all the enums be resorted alphabetically. (now or later). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15556#discussion_r1318671548 From duke at openjdk.org Thu Sep 7 14:10:20 2023 From: duke at openjdk.org (Soumadipta Roy) Date: Thu, 7 Sep 2023 14:10:20 GMT Subject: RFR: 8315683: Parallelize java/util/concurrent/tck/JSR166TestCase.java [v2] In-Reply-To: References: Message-ID: > This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations: > before : make test CONF=macosx-aarch64-server-fastdebug 200.64s user 20.94s system 204% cpu 1:48.47 total > fully parallel : make test CONF=macosx-aarch64-server-fastdebug 308.84s user 23.75s system 479% cpu 1:09.42 total > default-details-tck : make test CONF=macosx-aarch64-server-fastdebug 244.69s user 22.03s system 314% cpu 1:24.94 total > default-fjp_details-tck : make test CONF=macosx-aarch64-server-fastdebug 260.12s user 24.47s system 404% cpu 1:10.31 total > > Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination. Soumadipta Roy has updated the pull request incrementally with one additional commit since the last revision: Remove extra new line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15619/files - new: https://git.openjdk.org/jdk/pull/15619/files/591b1134..1482259c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15619&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15619&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15619/head:pull/15619 PR: https://git.openjdk.org/jdk/pull/15619 From rriggs at openjdk.org Thu Sep 7 14:18:48 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 7 Sep 2023 14:18:48 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v21] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Wed, 6 Sep 2023 22:22:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > use ByteArrayLittleEndian Looks good, thank you for your patience. For future performance PRs, please put the detailed performance data in a separate comment, not the description. The description is included in every email and the perf data gets out of date quickly. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14699#pullrequestreview-1615561446 From simone.bordet at gmail.com Thu Sep 7 14:38:25 2023 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 7 Sep 2023 16:38:25 +0200 Subject: Java 21 clinit deadlock Message-ID: Hello, We switched the Jetty builds to Java 21 a while ago, and they randomly fail with a hard deadlock during class initialization. We tried to understand if we were doing something wrong, but the code compiles fine, and at first glance there seems to be nothing wrong with it, but it may well be a popular Java puzzler that I am not aware of :) We did not see these failures with Java 20, and we do not see them with Java 17. I was wondering if something changed in Java 21 to cause this deadlock? I hope this is the right mailing list for this problem. If not, please let me know. I am an OpenJDK author so I can open an issue about this, but I don't have a reproducer, since it seems a race condition happening randomly. Below you can find more details about this deadlock. Thanks! ---- Taking a thread dump we see one thread in this state: java.lang.Thread.State: RUNNABLE at org.eclipse.jetty.http.HttpFields.build(org.eclipse.jetty.http at 12.0.2-SNAPSHOT/HttpFields.java:76) - waiting on the Class initialization monitor for org.eclipse.jetty.http.MutableHttpFields at org.eclipse.jetty.http.HttpFields.(org.eclipse.jetty.http at 12.0.2-SNAPSHOT/HttpFields.java:67) "ForkJoinPool-1-worker-1" #23 [1457161] daemon prio=5 os_prio=0 cpu=320.77ms elapsed=8870.98s allocated=18414K defined_classes=928 tid=0x00007f6ec0c6a6f0 nid=1457161 waiting on condition [0x00007f6e91ffb000] And other threads are in this state (or similar -- the bottom frame is different but still triggering the clinit of HttpFields): java.lang.Thread.State: RUNNABLE at org.eclipse.jetty.http.HttpTester.parseResponse(org.eclipse.jetty.http at 12.0.2-SNAPSHOT/HttpTester.java:274) - waiting on the Class initialization monitor for org.eclipse.jetty.http.HttpFields at org.eclipse.jetty.http.HttpTester.parseResponse(org.eclipse.jetty.http at 12.0.2-SNAPSHOT/HttpTester.java:261) "ForkJoinPool-1-worker-2" #24 [1457162] daemon prio=5 os_prio=0 cpu=136.15ms elapsed=8870.96s allocated=3303K defined_classes=340 tid=0x00007f6e4c01ddb0 nid=1457162 waiting on condition [0x00007f6e91efc000] Class hierarchy: MutableHttpFields implements HttpFields.Mutable HttpFields.Mutable extends HttpFields Full thread dump: https://gist.github.com/olamy/7e883adcf51b2410337abfa775a79a0b Code: https://github.com/eclipse/jetty.project/blob/jetty-12.0.1/jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpFields.java -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rriggs at openjdk.org Thu Sep 7 14:46:44 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 7 Sep 2023 14:46:44 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v4] In-Reply-To: <86maccfrzpjxVqqle-l3ZVAU9kadnS-_jSx-Dc9PZt8=.3ef956b6-8eee-4664-aab2-e676b37821bb@github.com> References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> <86maccfrzpjxVqqle-l3ZVAU9kadnS-_jSx-Dc9PZt8=.3ef956b6-8eee-4664-aab2-e676b37821bb@github.com> Message-ID: On Mon, 4 Sep 2023 11:01:06 GMT, Matthias Baesken wrote: >> We run into some BackingStoreException: Couldn't get file lock. e.g. here : >> >> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) >> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) >> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) >> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) >> [JShell] ... 4 more >> >> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Use PrivilegedAction to get OS name src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 36: > 34: import sun.util.logging.PlatformLogger; > 35: > 36: Extra blank line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1318702833 From duke at openjdk.org Thu Sep 7 15:05:54 2023 From: duke at openjdk.org (Qing Xiao) Date: Thu, 7 Sep 2023 15:05:54 GMT Subject: Integrated: 8315444: Convert test/jdk/tools to Classfile API In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 08:14:26 GMT, Qing Xiao wrote: > `/test/jdk/tools/lib/tests/JImageValidator.java`, tests in `/test/jdk/tools/jlink`, and `/test/jdk/tools/jimage`, `/test/jdk/java/time/nontestng/java/time/chrono/HijrahConfigTest.java` use on com.sun.tools.classfile and should be converted to Classfile API. This pull request has now been integrated. Changeset: 2fd870a7 Author: Qing Xiao Committer: Adam Sotona URL: https://git.openjdk.org/jdk/commit/2fd870a74fb35cb55b69f0dc6bf041441d658ffa Stats: 153 lines in 24 files changed: 95 ins; 11 del; 47 mod 8315444: Convert test/jdk/tools to Classfile API Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/15529 From jlu at openjdk.org Thu Sep 7 15:48:18 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 7 Sep 2023 15:48:18 GMT Subject: RFR: 8315410: Undocumented exceptions in java.text.StringCharacterIterator [v3] In-Reply-To: References: Message-ID: <4mivha1Ibx259OtguTlaXwkuJlaLKoT5zAUkqUhmfNI=.d7892255-882a-4678-90b6-7c7ed3610eaf@github.com> > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315558) which is a conformance change to document some exceptions in the specification of java.text.StringCharacterIterator. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: CSR review: replace constructor throws tag with a blanket class statement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15547/files - new: https://git.openjdk.org/jdk/pull/15547/files/58c3f396..9d44aa07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15547&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15547&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15547/head:pull/15547 PR: https://git.openjdk.org/jdk/pull/15547 From bpb at openjdk.org Thu Sep 7 16:01:41 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Sep 2023 16:01:41 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 08:33:39 GMT, Alan Bateman wrote: > Would it be possible to summarise how this behaves when File just represents a prefix? Baseline: jshell> File f = new File("\\\?\") f ==> \? jshell> f.getCanonicalPath() | Exception java.io.IOException: Bad pathname | at WinNTFileSystem.canonicalize0 (Native Method) | at WinNTFileSystem.canonicalize (WinNTFileSystem.java:463) | at File.getCanonicalPath (File.java:626) | at (#2:1) jshell> f = new File("\\\?\\UNC\") f ==> \?\UNC jshell> f.getCanonicalPath() | Exception java.io.IOException: Bad pathname | at WinNTFileSystem.canonicalize0 (Native Method) | at WinNTFileSystem.canonicalize (WinNTFileSystem.java:463) | at File.getCanonicalPath (File.java:626) | at (#4:1) Proposed patch: jshell> File f = new File("\\\?\") f ==> \? jshell> f.getCanonicalPath() | Exception java.io.IOException: Bad pathname | at WinNTFileSystem.canonicalize0 (Native Method) | at WinNTFileSystem.canonicalize (WinNTFileSystem.java:472) | at File.getCanonicalPath (File.java:626) | at (#2:1) jshell> f = new File("\\\?\\UNC\") f ==> \?\UNC jshell> f.getCanonicalPath() $4 ==> "C:\\Users\\bpb\\dev\\jdk\\jdk\\UNC" Presumably the constructor removes the trailing `\`, hence I suppose the special case of `\?\UNC` should be checked in the code right after the proposed change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1710409880 From martin at openjdk.org Thu Sep 7 16:01:45 2023 From: martin at openjdk.org (Martin Buchholz) Date: Thu, 7 Sep 2023 16:01:45 GMT Subject: RFR: 8315683: Parallelize java/util/concurrent/tck/JSR166TestCase.java [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 14:10:20 GMT, Soumadipta Roy wrote: >> This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations: >> >> * before : **200.64s user 20.94s system 204% cpu 1:48.47 total** >> * fully parallel : **308.84s user 23.75s system 479% cpu 1:09.42 total** >> * default-details-tck : **244.69s user 22.03s system 314% cpu 1:24.94 total** >> * default-fjp_details-tck : **260.12s user 24.47s system 404% cpu 1:10.31 total** >> >> Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination. > > Soumadipta Roy has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra new line test/jdk/java/util/concurrent/tck/JSR166TestCase.java line 39: > 37: /* > 38: * @test id=default > 39: * @summary JSR-166 tck tests, in a number of variations. The @summary is stale - it describes the state when there was only one @test test/jdk/java/util/concurrent/tck/JSR166TestCase.java line 45: > 43: * @modules java.management > 44: * @run junit/othervm/timeout=1000 JSR166TestCase > 45: * @run junit/othervm/timeout=1000 -Djava.security.manager=allow JSR166TestCase security manager testing is relatively less important. I would move this to a lower tier, while moving a test with -Djsr166.testImplementationDetails=true into tier1 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15619#discussion_r1318817536 PR Review Comment: https://git.openjdk.org/jdk/pull/15619#discussion_r1318820512 From martin at openjdk.org Thu Sep 7 16:10:41 2023 From: martin at openjdk.org (Martin Buchholz) Date: Thu, 7 Sep 2023 16:10:41 GMT Subject: RFR: 8315683: Parallelize java/util/concurrent/tck/JSR166TestCase.java [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 14:10:20 GMT, Soumadipta Roy wrote: >> This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations: >> >> * before : **200.64s user 20.94s system 204% cpu 1:48.47 total** >> * fully parallel : **308.84s user 23.75s system 479% cpu 1:09.42 total** >> * default-details-tck : **244.69s user 22.03s system 314% cpu 1:24.94 total** >> * default-fjp_details-tck : **260.12s user 24.47s system 404% cpu 1:10.31 total** >> >> Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination. > > Soumadipta Roy has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra new line Hello Soumadipta - pleased to "meet" you. If the intent is to split the tests into relatively more and less important variants for placing into separate tiers, that should be clear from the @summary's in the tests. ------------- Changes requested by martin (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15619#pullrequestreview-1615792268 From mandy.chung at oracle.com Thu Sep 7 16:16:57 2023 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 7 Sep 2023 09:16:57 -0700 Subject: Question on why sun.management MBeans are not exported? In-Reply-To: References: <1535aa6e-6865-d885-3930-df7f9ebcb4b4@oracle.com> <70186c9a-79ba-e63d-7ed9-1033dece525c@oracle.com> Message-ID: <181c2756-aced-8656-f45a-d78d5ccc7865@oracle.com> What we're referring to is to remove sun.management.Hotspot*, the internal MBeans which are never exposed and registered in the platform MBeanServer.?? The internal metrics in HotSpot VM should be retained as they are exposed through other ways like jstat, GC logs, etc. Mandy On 9/6/23 11:27 PM, Kirk Pepperdine wrote: > Hi, > > It would be a shame to lose these metrics because many of them have been very useful over time and some would be even more useful with some modifications. For example, the CPU breakouts found in GC logs has been incredibly useful as a proxy measure in helping sort out other issues in systems. So much so that I have analytics built specifically around this in my tooling. > > Kind regards, > Kirk Pepperdine > > >> On Sep 6, 2023, at 10:50 AM, Alan Bateman wrote: >> >> On 06/09/2023 16:17, Volker Simonis wrote: >>> : >>> I'm familiar with JEP 260. But wouldn't you agree that an >>> "encapsulated" monitoring API is an oxymoron? A monitoring API is by >>> design intended for external usage and completely useless to the >>> platform itself. There's no single usage of the "sun.management" >>> MBeans in the JDK itself (except for jconsole where the encapsulation >>> broke it). My assumption is that the corresponding MBeans in >>> "sun.management" are there for historic reasons (added in JDK 1.5) and >>> would have made much more sense in "com.sun.management" package. But I >>> doubt that they can be classified in the "internal implementation >>> details of the JDK and never intended for external use? category of >>> JEP 260. >> It's left over from experiments on exposing some internal metrics, I think during JDK 5. It's code that should probably have been removed a long time ago. >> >> -Alan From shade at openjdk.org Thu Sep 7 16:21:18 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Sep 2023 16:21:18 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v3] In-Reply-To: References: Message-ID: > Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Revert "Switch to PPC32" This reverts commit d829d243f94560dc19699d36b67a73280817b8f6. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15556/files - new: https://git.openjdk.org/jdk/pull/15556/files/d829d243..df419e36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15556&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15556&range=01-02 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15556/head:pull/15556 PR: https://git.openjdk.org/jdk/pull/15556 From shade at openjdk.org Thu Sep 7 16:21:19 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Sep 2023 16:21:19 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:51:31 GMT, Aleksey Shipilev wrote: >> Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Switch to PPC32 > - Merge branch 'master' into JDK-8315578-ppc-builds > - Fix Yeah, so as I see from GHA testing: STARTED ArchTest::checkParams '[8] ppc, PPC32, 32, BIG_ENDIAN, false' java.lang.IllegalArgumentException: No enum constant jdk.internal.util.Architecture.PPC at java.base/java.lang.Enum.valueOf(Enum.java:293) at java.base/jdk.internal.util.Architecture.valueOf(Architecture.java:39) at java.base/jdk.internal.util.Architecture.lookupByName(Architecture.java:99) at ArchTest.checkParams(ArchTest.java:120) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) The test would verify that enum names are consistent with `os.arch`. Which would be `ppc`, based on build system pick. Therefore, we cannot do PPC32. I reverted the previous commit... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15556#issuecomment-1710435235 From duke at openjdk.org Thu Sep 7 16:24:44 2023 From: duke at openjdk.org (Soumadipta Roy) Date: Thu, 7 Sep 2023 16:24:44 GMT Subject: RFR: 8315683: Parallelize java/util/concurrent/tck/JSR166TestCase.java [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 15:58:26 GMT, Martin Buchholz wrote: >> Soumadipta Roy has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove extra new line > > test/jdk/java/util/concurrent/tck/JSR166TestCase.java line 45: > >> 43: * @modules java.management >> 44: * @run junit/othervm/timeout=1000 JSR166TestCase >> 45: * @run junit/othervm/timeout=1000 -Djava.security.manager=allow JSR166TestCase > > security manager testing is relatively less important. I would move this to a lower tier, while moving a test with -Djsr166.testImplementationDetails=true into tier1 Hi Martin, I will raise another commit trying to add summary for the segregations ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15619#discussion_r1318854380 From jvernee at openjdk.org Thu Sep 7 16:26:48 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 7 Sep 2023 16:26:48 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v17] 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: Split long throws clauses in `MemorySegment` javadoc Reviewed-by: jvernee ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/55296527..2f50adbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=15-16 Stats: 41 lines in 1 file changed: 3 ins; 0 del; 38 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 shade at openjdk.org Thu Sep 7 16:27:46 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Sep 2023 16:27:46 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 14:07:05 GMT, Roger Riggs wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Switch to PPC32 >> - Merge branch 'master' into JDK-8315578-ppc-builds >> - Fix > > src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 62: > >> 60: static final boolean TARGET_ARCH_IS_LOONGARCH64 = "@@OPENJDK_TARGET_CPU@@" == "loongarch64"; >> 61: static final boolean TARGET_ARCH_IS_S390 = "@@OPENJDK_TARGET_CPU@@" == "s390"; >> 62: static final boolean TARGET_ARCH_IS_PPC32 = "@@OPENJDK_TARGET_CPU@@" == "ppc"; > > The list is getting longer. I'd suggest/request that all the enums be resorted alphabetically. (now or later). I think later? Don't want to keep retesting the PR for accidental problems during reshuffle :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15556#discussion_r1318857471 From duke at openjdk.org Thu Sep 7 17:12:38 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Thu, 7 Sep 2023 17:12:38 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote: > This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. > > This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: > > > Name Cnt Base Error Test Error Unit Diff% > HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) > :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) > :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 0,000 0,000 counts > HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) > :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) > :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) > :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) > :gc.count 15 0,000 0,000 ... You can refer to the PR #14745 I submitted. Using a table with a length of 256 in HexDigits, you can get two digits in one lookup table, and use ByteArrayLittleEndian.setShort to write two digits at a time. like this: public String toHexDigits(byte value) { byte[] rep = new byte[2]; ByteArrayLittleEndian.setShort(rep, 0, HexDigits.DIGITS[value & 0xff]); // DIGITS shuld changed to little-endian try { return jla.newStringNoRepl(rep, StandardCharsets.ISO_8859_1); } catch (CharacterCodingException cce) { throw new AssertionError(cce); } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/15591#issuecomment-1710508831 From vromero at openjdk.org Thu Sep 7 17:18:56 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 7 Sep 2023 17:18:56 GMT Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v11] In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> References: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> Message-ID: On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona wrote: >> javap uses proprietary com.sun.tools.classfile library to parse class files. >> >> This patch converts javap to use Classfile API. >> >> Please review. >> >> 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 227 commits: > > - Merge branch 'master' into JDK-8294969-javap > - Merge branch 'master' into JDK-8294969-javap > - fixed code printing and ConstantPoolException reporting indoex > - added DydnamicConstantPoolEntry::bootstrapMethodIndex > fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute > - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead > - throwing ConstantPoolException for invalid BSM entry index > - Merge branch 'master' into JDK-8294969-javap > - fixed JavapTask > - Merge branch 'master' into JDK-8294969-javap > - Merge branch 'master' into JDK-8294969-javap > > # Conflicts: > # src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java > - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 226: > 224: > 225: /** > 226: * {@return the field ref entry whose index is given at the specified I think that `ref` in these APIs should be `reference` src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java line 465: > 463: indent(+1); > 464: print("target_platform: #" + attr.targetPlatform().index()); > 465: //ToDo find the spec - can be null??? what about this comment? src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java line 549: > 547: case SourceIDAttribute attr -> > 548: constantWriter.write(attr.sourceId().index()); > 549: // case StackMapAttribute ??? I guess this comment can be removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318036242 PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318069041 PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318070357 From duke at openjdk.org Thu Sep 7 17:21:48 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Thu, 7 Sep 2023 17:21:48 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v11] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Tue, 5 Sep 2023 15:48:21 GMT, ??? wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) >> >> >> >> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) > > ??? has updated the pull request with a new target base 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 optimization_for_uuid_to_string > - remove redundant parentheses > - fix java doc, big-endian -> little-endian > - Merge branch 'master' into optimization_for_uuid_to_string > - use ByteArrayLittleEndian > - fix typo > - code style > - Explain the rationale > > Co-authored-by: liach > - private static final Unsafe > - revert to the previous version > - ... and 4 more: https://git.openjdk.org/jdk/compare/34d842c9...2d36332b @cl4es Can you help me review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1710520451 From pminborg at openjdk.org Thu Sep 7 17:23:20 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 7 Sep 2023 17:23:20 GMT Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes [v2] In-Reply-To: References: Message-ID: > This PR proposes to slightly improve some iterators of `AbstractMap`: > > * Code reuse > * A field declared `final` > * Add missing `@Override` annotations Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove @Override annotations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15615/files - new: https://git.openjdk.org/jdk/pull/15615/files/1b00c84b..aab2472a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15615&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15615&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 10 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 jlu at openjdk.org Thu Sep 7 17:24:24 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 7 Sep 2023 17:24:24 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v3] In-Reply-To: References: Message-ID: > Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern. > > `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified. > > The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor. > > The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Reflect Naoto's comments from 9/6 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15392/files - new: https://git.openjdk.org/jdk/pull/15392/files/fd1cc831..bbb99eb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=01-02 Stats: 41 lines in 1 file changed: 16 ins; 17 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15392/head:pull/15392 PR: https://git.openjdk.org/jdk/pull/15392 From jlu at openjdk.org Thu Sep 7 17:24:31 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 7 Sep 2023 17:24:31 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v2] In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 23:04:59 GMT, Naoto Sato wrote: > Could the first choice be more specific? Updated with a more syntactical definition. Please let me know if you think this is _too_ specific. > Also, do SubPatterns need to be sorted with Limits? If I am interpreting the question right, you're asking if a subPattern **needs** a limit to be valid. If that's the question, the answer is yes, `ChoiceFormat` is designed to have an equal amount of limits and formats (whether from the arrays, or the String pattern). But please let me know if I misinterpreted the question. subpattern "xyz" where both _limit_ and _relation_ are omitted jshell> var a = new ChoiceFormat("0#abc|xyz") a ==> java.text.ChoiceFormat at 17863 jshell> a.getLimits() $21 ==> double[1] { 0.0 } jshell> a.getFormats() $22 ==> String[1] { "abc" } subpattern "#xyz" where _limit_ is omitted jshell> var b = new ChoiceFormat("0#abc|#xyz") | Exception java.lang.IllegalArgumentException: Each interval must contain a number before a format > src/java.base/share/classes/java/text/ChoiceFormat.java line 152: > >> 150: * >> 151: * System.out.println("Format with -INF : " + fmt.format(Double.NEGATIVE_INFINITY)); >> 152: * // ... > > Commenting out (with ellipsis) would not print the result below I felt it was redundant to have both the long lines of println and output, so I commented out the println(s) except for the ones of interest, which are `Double.NEGATIVE_INFINITY`, `Double.POSITIVE_INFINITY`, and `Double.NaN`. However, you're right that commenting it out would not print the below result. I have updated it so that the println and output lines are combined, to provide a more concise example. > src/java.base/share/classes/java/text/ChoiceFormat.java line 407: > >> 405: >> 406: /** >> 407: * Get the formats of this ChoiceFormat. > > Same here Fixed, as well as in the other instance, I have also updated https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html to reflect the changes. Thanks for the review ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1318912438 PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1318912460 PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1318912398 From rriggs at openjdk.org Thu Sep 7 17:50:42 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 7 Sep 2023 17:50:42 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v14] In-Reply-To: References: Message-ID: On Tue, 5 Sep 2023 22:47:01 GMT, Naoto Sato wrote: >> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Incorporating suggested changes Looking very good. src/java.base/share/classes/java/text/ListFormat.java line 95: > 93: * On parsing, if some ambiguity is found in the input string, such as delimiting > 94: * sequences being found in the input string, may produce the result that when formatted is not a > 95: * round-trip with the corresponding formatting. For example, a two element String list Suggestion: * On parsing, if some ambiguity is found in the input string, such as delimiting * sequences in the input string, the result, when formatted with the same formatting, does not * re-produce the input string . For example, a two element String list src/java.base/share/classes/java/text/ListFormat.java line 345: > 343: * of Object. > 344: * @param toAppendTo where the text is to be appended > 345: * @param pos Ignored. Not used in ListFormat. May be null Curious, why not used? I could see a use to identity the string inserted to enable highlighting or other markup around the new string. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15130#pullrequestreview-1615880405 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1318891558 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1318935751 From smarks at openjdk.org Thu Sep 7 17:53:38 2023 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 7 Sep 2023 17:53:38 GMT Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 17:23:20 GMT, Per Minborg wrote: >> This PR proposes to slightly improve some iterators of `AbstractMap`: >> >> * Code reuse >> * A field declared `final` >> * Add missing `@Override` annotations > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove @Override annotations Note, I had asked @minborg to remove the `@Override` annotations. They're generally not used in the collections framework, and where they are, they add a lot of clutter but not much value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15615#issuecomment-1710557583 From smarks at openjdk.org Thu Sep 7 18:08:37 2023 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 7 Sep 2023 18:08:37 GMT Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 12:24:58 GMT, R?mi Forax wrote: >> This PR proposes to slightly improve some iterators of `AbstractMap`: >> >> * Code reuse >> * A field declared `final` >> * Add missing `@Override` annotations > > Hello, > In Java, sharing code may have a runtime cost (or not) depending on the shape of the code, because the VM may have to speculate on the class of some value at runtime. > Here, in hasNext() and remove(), the VM has to find the class of the field 'i' at runtime. > > Iterators are performance sentive (they are used in for loop) and for that they need the escape analysis to work. > If the iterator code is polymorphic, so part of the code may be unknown so the escape analysis will consider that the iterator escape. So usually, it's a good practice to not share the iterator code. > > Also the field should be package private (or even maybe private) but not protected. Protected is very rare in Java because usually classes that share implementation details are in the same package (or in the same nestmate nest). @forax Note that HashMap uses a similar subclassing idiom for the iterators of the keySet, values, and entrySet collections in order to share the iterator logic: https://github.com/openjdk/jdk/blob/jdk-21%2B35/src/java.base/share/classes/java/util/HashMap.java#L1626 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15615#issuecomment-1710574566 From naoto at openjdk.org Thu Sep 7 18:20:28 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 7 Sep 2023 18:20:28 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v15] In-Reply-To: References: Message-ID: > Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision: - Reflects review comments - Merge branch 'master' into JDK-8041488-ListPatterns-PR - Incorporating suggested changes - Update src/java.base/share/classes/java/text/ListFormat.java Co-authored-by: Roger Riggs - Update src/java.base/share/classes/java/text/ListFormat.java Co-authored-by: Roger Riggs - Update src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java Co-authored-by: Roger Riggs - Removing unnecessary commas - Added tests - Review comments - Merge branch 'master' into JDK-8041488-ListPatterns-PR - ... and 14 more: https://git.openjdk.org/jdk/compare/85b25b37...bce82a4f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15130/files - new: https://git.openjdk.org/jdk/pull/15130/files/316ed12d..bce82a4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=13-14 Stats: 18706 lines in 454 files changed: 13614 ins; 2714 del; 2378 mod Patch: https://git.openjdk.org/jdk/pull/15130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130 PR: https://git.openjdk.org/jdk/pull/15130 From mchung at openjdk.org Thu Sep 7 18:22:40 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 7 Sep 2023 18:22:40 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v11] In-Reply-To: References: Message-ID: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` > can be used instead and such stack walker will save the overhead of extracting the method information > and the memory used for the stack walking. > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can create a stack walker instance with `DROP_METHOD_INFO` option: > > > StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(Predicate.not(implClasses::contains)) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Javadoc & specdiff > > https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html > https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > ### Implementation Details > > A `StackWalker` configured with `DROP_METHOD_INFO` option creates `ClassFrameInfo[]` > buffer that is filled by the VM during stack walking. `Sta... Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15370/files - new: https://git.openjdk.org/jdk/pull/15370/files/a623b9dc..0e6abc42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=09-10 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From bchristi at openjdk.org Thu Sep 7 18:37:44 2023 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 7 Sep 2023 18:37:44 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v11] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 18:22:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback Looks great - thanks! ------------- Marked as reviewed by bchristi (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1616029850 From dfuchs at openjdk.org Thu Sep 7 18:56:51 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 7 Sep 2023 18:56:51 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v11] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 18:22:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback Changes requested by dfuchs (Reviewer). test/micro/org/openjdk/bench/java/lang/StackWalkBench.java line 60: > 58: static StackWalker walker(String name) { > 59: return switch (name) { > 60: case "class+method" -> WALKER; don't you need to also change "default" into "class+method" in the `@Param({"default", "class_only"})` annotations below? test/micro/org/openjdk/bench/java/lang/StackWalkBench.java line 78: > 76: public int mark = 4; > 77: > 78: @Param({"default", "class_only"}) (I mean here) ------------- PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1616052545 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1318997721 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1318999463 From jvernee at openjdk.org Thu Sep 7 19:01:25 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 7 Sep 2023 19:01:25 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v18] 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: add code snippet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/2f50adbf..86a7e227 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=16-17 Stats: 6 lines in 1 file changed: 5 ins; 0 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 forax at openjdk.org Thu Sep 7 19:01:38 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 7 Sep 2023 19:01:38 GMT Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 18:05:51 GMT, Stuart Marks wrote: >> Hello, >> In Java, sharing code may have a runtime cost (or not) depending on the shape of the code, because the VM may have to speculate on the class of some value at runtime. >> Here, in hasNext() and remove(), the VM has to find the class of the field 'i' at runtime. >> >> Iterators are performance sentive (they are used in for loop) and for that they need the escape analysis to work. >> If the iterator code is polymorphic, so part of the code may be unknown so the escape analysis will consider that the iterator escape. So usually, it's a good practice to not share the iterator code. >> >> Also the field should be package private (or even maybe private) but not protected. Protected is very rare in Java because usually classes that share implementation details are in the same package (or in the same nestmate nest). > > @forax Note that HashMap uses a similar subclassing idiom for the iterators of the keySet, values, and entrySet collections in order to share the iterator logic: > > https://github.com/openjdk/jdk/blob/jdk-21%2B35/src/java.base/share/classes/java/util/HashMap.java#L1626 Hi @stuart-marks , for HashMap, all the fields of HashIterator have only one implementation, in this patch, the field of AbstractIterator is typed Iterator (so multiple implementations at runtime). This is not the same code shape. I think the best is to write a simple to test that iterate over both the keySet() and the values() of an implementation of AbstractMap that only defines size() and get() and use -XX:+PrintInlining to see if the VM reports a profile pollution for the code before and after this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15615#issuecomment-1710632697 From mchung at openjdk.org Thu Sep 7 19:07:52 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 7 Sep 2023 19:07:52 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v11] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 18:51:44 GMT, Daniel Fuchs wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> review feedback > > test/micro/org/openjdk/bench/java/lang/StackWalkBench.java line 60: > >> 58: static StackWalker walker(String name) { >> 59: return switch (name) { >> 60: case "class+method" -> WALKER; > > don't you need to also change "default" into "class+method" in the `@Param({"default", "class_only"})` annotations below? thanks for catching it. will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1319009375 From mchung at openjdk.org Thu Sep 7 19:27:14 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 7 Sep 2023 19:27:14 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v12] In-Reply-To: References: Message-ID: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` > can be used instead and such stack walker will save the overhead of extracting the method information > and the memory used for the stack walking. > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can create a stack walker instance with `DROP_METHOD_INFO` option: > > > StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(Predicate.not(implClasses::contains)) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Javadoc & specdiff > > https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html > https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > ### Implementation Details > > A `StackWalker` configured with `DROP_METHOD_INFO` option creates `ClassFrameInfo[]` > buffer that is filled by the VM during stack walking. `Sta... Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Fix @Param due to the rename from default to class+method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15370/files - new: https://git.openjdk.org/jdk/pull/15370/files/0e6abc42..c3746f5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From dfuchs at openjdk.org Thu Sep 7 19:30:47 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 7 Sep 2023 19:30:47 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v12] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 19:27:14 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Fix @Param due to the rename from default to class+method Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1616112038 From naoto at openjdk.org Thu Sep 7 19:37:39 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 7 Sep 2023 19:37:39 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 17:18:33 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/text/ChoiceFormat.java line 136: >> >>> 134: * Limit Relation Format >>> 135: * Limit: >>> 136: * {@code String} that can be parsed as a {@code double} / "∞" ({@code U+221E}) / "-∞" (-{@code U+221E}). >> >> Could the first choice be more specific? Also, do `SubPattern`s need to be sorted with `Limit`s? > >> Could the first choice be more specific? > > Updated with a more syntactical definition. Please let me know if you think this is _too_ specific. > >> Also, do SubPatterns need to be sorted with Limits? > > If I am interpreting the question right, you're asking if a subPattern **needs** a limit to be valid. If that's the question, the answer is yes, `ChoiceFormat` is designed to have an equal amount of limits and formats (whether from the arrays, or the String pattern). But please let me know if I misinterpreted the question. > > subpattern "xyz" where both _limit_ and _relation_ are omitted > > jshell> var a = new ChoiceFormat("0#abc|xyz") > a ==> java.text.ChoiceFormat at 17863 > jshell> a.getLimits() > $21 ==> double[1] { 0.0 } > jshell> a.getFormats() > $22 ==> String[1] { "abc" } > > > subpattern "#xyz" where _limit_ is omitted > > jshell> var b = new ChoiceFormat("0#abc|#xyz") > | Exception java.lang.IllegalArgumentException: Each interval must contain a number before a format Please let me know if you think this is too specific. I think the updated one is better. For the second part, I meant: jshell> new ChoiceFormat("0#def|-1#abc|xyz") | Exception java.lang.IllegalArgumentException: Incorrect order of intervals, must be in ascending order This should be excluded from the pattern syntax ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1319041104 From rriggs at openjdk.org Thu Sep 7 20:00:44 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 7 Sep 2023 20:00:44 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v11] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Tue, 5 Sep 2023 15:48:21 GMT, ??? wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) >> >> >> >> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) > > ??? has updated the pull request with a new target base 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 optimization_for_uuid_to_string > - remove redundant parentheses > - fix java doc, big-endian -> little-endian > - Merge branch 'master' into optimization_for_uuid_to_string > - use ByteArrayLittleEndian > - fix typo > - code style > - Explain the rationale > > Co-authored-by: liach > - private static final Unsafe > - revert to the previous version > - ... and 4 more: https://git.openjdk.org/jdk/compare/b801e29e...2d36332b src/java.base/share/classes/java/util/HexDigits.java line 54: > 52: for (int j = 0; j < 16; j++) { > 53: short lo = (short) ((j < 10 ? j + '0' : j - 10 + 'a') << 8); > 54: digits[(i << 4) + j] = (short) (hi | lo); The variable naming and this `hi | lo` expression are counter-intuitive; they should be reversed to be consistent with the little-endian bit layout. A description of the DIGITS array layout and indexing is needed; it will help with the comprehension of the masking and shifts in the packDigits methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1318950015 From psandoz at openjdk.org Thu Sep 7 20:25:55 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 7 Sep 2023 20:25:55 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v33] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 21:31:40 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: > > Change name of the avxsort library to libx86_64_sort Focusing on the Java changes, I am glad you managed to introduce intrinsics into the main Java sorting loop, with leaf array sorting and array partitioning thereby taking advantage of existing functionality. Initially i advised trying to make the intrinsic work across heap and off-heap data, e.g., sorting `MemorySegment`. I still think that is a worthy goal, but we don't need to do that now, but I still think intrinsics should be base+offset shaped in preparation for that. I think we need to summarize future planned steps, some i believe were discussed with regards to the C++ code, but i don't recall if AVX2 was discussed. Specifically for this patch. It would be useful to use a consistent order of `low`, `end`, `high` arguments/parameters, and set `end = high` rather than `end = -1`. Related to that i notice `mixedInsertionSort` has logic to check if `end == high` and performs something similar to `insertionSort`. Perhaps we can combine? (I don't know if the original code was split for some performance advantage.) We could shape the intrinsic in a similar way to how we do so for the Vector API, assuming there is no performance disadvantage when the intrinsic is disabled or not available e.g, something like this: @FunctionalInterface interface SortOperation { void sort(A a, int low, int end int high); } // A erases to Object in bytecode so i think it should work @IntrinsicCandidate @ForceInline private static void arraySort(Class eClass, A a, long offset, int low, int end, int high, SortOperation so) { so.sort(a, low, end, high); } Then we can pass a method reference as the last argument to the method. Thereby we avoid the switch over the array class. Now we have the overall recursive loop in Java how important is it there be a similar kind of loop in the native sort? I suppose it depends on the thresholds when called, but maybe there is an opportunity to simplify, which may help if in the future we move away of C++ code to assembler. ------------- PR Review: https://git.openjdk.org/jdk/pull/14227#pullrequestreview-1616187224 From jlu at openjdk.org Thu Sep 7 20:29:11 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 7 Sep 2023 20:29:11 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v4] In-Reply-To: References: Message-ID: > Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern. > > `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified. > > The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor. > > The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Review: Make ascending format clear, improve syntax, remove unicode sequences ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15392/files - new: https://git.openjdk.org/jdk/pull/15392/files/bbb99eb4..e3dafe6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=02-03 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15392/head:pull/15392 PR: https://git.openjdk.org/jdk/pull/15392 From jlu at openjdk.org Thu Sep 7 20:29:11 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 7 Sep 2023 20:29:11 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 19:35:06 GMT, Naoto Sato wrote: > This should be excluded from the pattern syntax I presume you meant that the syntax should _include_ the required ascending order of limits. Updated to make this apparent, I also adjusted the syntax a little bit to be more accurate. The previous syntax could technically have an empty _Number_ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1319085087 From mchung at openjdk.org Thu Sep 7 21:40:57 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 7 Sep 2023 21:40:57 GMT Subject: Integrated: 8268829: Provide an optimized way to walk the stack with Class object only In-Reply-To: References: Message-ID: <-WTzPHcQRUICXBu_u26_37O8oRcACfyZkwquhz8dg9Y=.91014937-6a56-4c06-be60-47f933d94c14@github.com> On Mon, 21 Aug 2023 20:07:20 GMT, Mandy Chung wrote: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` > can be used instead and such stack walker will save the overhead of extracting the method information > and the memory used for the stack walking. > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can create a stack walker instance with `DROP_METHOD_INFO` option: > > > StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(Predicate.not(implClasses::contains)) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Javadoc & specdiff > > https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html > https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > ### Implementation Details > > A `StackWalker` configured with `DROP_METHOD_INFO` option creates `ClassFrameInfo[]` > buffer that is filled by the VM during stack walking. `Sta... This pull request has now been integrated. Changeset: 111ecdba Author: Mandy Chung URL: https://git.openjdk.org/jdk/commit/111ecdbaf58e5c0b3a64e0eca8a291df295e71b0 Stats: 1340 lines in 34 files changed: 718 ins; 358 del; 264 mod 8268829: Provide an optimized way to walk the stack with Class object only 8210375: StackWalker::getCallerClass throws UnsupportedOperationException Reviewed-by: coleenp, dfuchs, bchristi ------------- PR: https://git.openjdk.org/jdk/pull/15370 From tprinzing at openjdk.org Thu Sep 7 21:50:17 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Thu, 7 Sep 2023 21:50:17 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v5] In-Reply-To: References: Message-ID: > The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable. > > JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support. > > In the java.base module: > Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent. > java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events. > > In the jdk.jfr module: > jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events. > In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes. > > The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation: > Passed: jdk/jfr/event/io/TestSocketChannelEvents.java > Passed: jdk/jfr/event/io/TestSocketEvents.java > > I added a micro benchmark which measures the overhead of handling the jfr socket events. > test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java. > It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments. > At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: More changes from review: I didn't like the name of the helper method 'checkForCommit' because it doesn't indicate that it might commit the event. I also don't like 'commitEvent' because it might not. Since JFR events are sort of like a queue I went with a name from collections and called it 'offer' so using it is something like 'SocketReadEvent.offer(...)' which seems like it gets the idea across better. Also improved the javadoc for it. Removed the comments about being instrumented by JFR in Socket.SocketInputStream and Socket.SocketOutputStream. I went ahead and moved the event commiting out of the finally block so that we don't emit events when the read/write did not actually happen. The bugid JDK-8310979 will be used to determine if more should be done in this area. The implRead and implWrite were moved up with the other support methods for read/write. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14342/files - new: https://git.openjdk.org/jdk/pull/14342/files/d6f7df72..9fa27459 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=03-04 Stats: 151 lines in 5 files changed: 57 ins; 81 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342 PR: https://git.openjdk.org/jdk/pull/14342 From tprinzing at openjdk.org Thu Sep 7 21:57:40 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Thu, 7 Sep 2023 21:57:40 GMT Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3] In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 07:18:21 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/net/Socket.java line 1133: >> >>> 1131: return parent.getSoTimeout(); >>> 1132: } catch (Throwable t) { >>> 1133: // ignored - avoiding exceptions in jfr event data gathering >> >> This should be SocketException, not Throwable. That said, I think it would be useful to know why the SocketReadEvent includes the timeout. Is this used to see If read durations are close to the timeout? I assume once this code is fixed to deal with the exceptional case that the need to include the timeout for the success case will mostly go away. > > Were you able to find out what the timeout is used for? No. I think it's a relic from the distant past though. I think the timeout field should be removed. It's not used on SocketChannel at all, and it doesn't seem useful on Socket. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1319152153 From redestad at openjdk.org Thu Sep 7 23:39:38 2023 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 7 Sep 2023 23:39:38 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote: > This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. > > This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: > > > Name Cnt Base Error Test Error Unit Diff% > HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) > :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) > :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 0,000 0,000 counts > HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) > :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) > :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) > :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) > :gc.count 15 0,000 0,000 ... I took `ByteArrayLittleEndian` for a spin on a (new) micro for `String toHexDigits(byte)`, and that gives us ~4% (MacBook M1): Name Cnt Base Error Test Error Unit Diff% HexFormatBench.toHexDigits 15 1,943 ? 0,014 1,862 ? 0,009 us/op 4,1% (p = 0,000*) * = significant I'm not sure 4% is a large enough win on a micro to motivate the lookup-table based approach. I'd rather see us investigate if we could consolidate these overlapping utility classes (`HexFormat` and `HexDigits`) on a lookup-table free solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15591#issuecomment-1710889268 From duke at openjdk.org Thu Sep 7 23:39:52 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 7 Sep 2023 23:39:52 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v33] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 21:31:40 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: > > Change name of the avxsort library to libx86_64_sort Hello Paul, Thank you for reviewing the code and providing your suggestions! > Focusing on the Java changes, I am glad you managed to introduce intrinsics into the main Java sorting loop, with leaf array sorting and array partitioning thereby taking advantage of existing functionality. > Using the decomposed approach, which you initially suggested, it's now possible to speedup both `Arrays.sort()` and `Arrays.parallelSort()` as only the partition and leaf level sort methods are being intrinsified. > Initially i advised trying to make the intrinsic work across heap and off-heap data, e.g., sorting `MemorySegment`. I still think that is a worthy goal, but we don't need to do that now, but I still think intrinsics should be base+offset shaped in preparation for that. > > I think we need to summarize future planned steps, some i believe were discussed with regards to the C++ code, but i don't recall if AVX2 was discussed. > Please see below, a summary of the future planned steps after the integration of this PR. The plan is to further speedup `DualPivotQuicksort.sort()` by 1. enabling AVX2 sort and partitioning for Linux (AVX2 sort using C++ and x86 SIMD intrinsics is being currently [worked upon](https://github.com/intel/x86-simd-sort/pull/60)). 2. adding Windows support for both AVX512 and AVX2 using assembly stubs. 3. enabling SIMD sort (both AVX512 and AVX2) for `MemorySegment`. 4. 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.) > Specifically for this patch. It would be useful to use a consistent order of `low`, `end`, `high` arguments/parameters, and set `end = high` rather than `end = -1`. Related to that i notice `mixedInsertionSort` has logic to check if `end == high` and performs something similar to `insertionSort`. Perhaps we can combine? (I don't know if the original code was split for some performance advantage.) > Currently, I am working on refactoring the code (which will be pushed shortly) to clean up the calls to `insertionSort` and `mixedInsertionSort`. The plan is to have separate intrinsics for both of those methods. (It may be possible to combine both. Will look into it as well.) > We could shape the intrinsic in a similar way to how we do so for the Vector API, assuming there is no performance disadvantage when the intrinsic is disabled or not available e.g, something like this: > > ```java > @FunctionalInterface > interface SortOperation { > void sort(A a, int low, int end int high); > } > > // A erases to Object in bytecode so i think it should work > @IntrinsicCandidate > @ForceInline > private static void arraySort(Class eClass, A a, long offset, int low, int end, int high, SortOperation so) { > so.sort(a, low, end, high); > } > ``` > > Then we can pass a method reference as the last argument to the method. Thereby we avoid the switch over the array class. > Currently there is a regression of up to 20%, when the intrinsic is disabled. This has been root caused to two reasons: - performance loss due to using a generalized intrinsic for all data types (`int, long, float, double`) with multiple indirections and `switch()` in the fallback method implementation. - performance loss due to passing a `pivotIndices` array to the partition methods and modifying it in place. Passing the pivot indices explicitly to the partition method and then returning the updated pivot indices from the method as a new array is fixing this regression. Refactoring the code to have type specific intrinsics for the sort and partition methods (coupled with returning a `pivotIndices` array) is fixing the regressions observed in cases when the intrinsics are either unsupported or disabled. Will push the code changes mentioned above shortly. At the same time, will also investigate the performance impact of the Vector API based idea suggested. > Now we have the overall recursive loop in Java how important is it there be a similar kind of loop in the native sort? I suppose it depends on the thresholds when called, but maybe there is an opportunity to simplify, which may help if in the future we move away of C++ code to assembler. > Currently, most of the recursive calls are executed in Java. For the existing small array thresholds, the recursion depth for the single pivot quicksort in the native implementation is at most 2. The only intrinsics we need are the vectorized bitonic sort (for `size <= 128`) and vectorized single pivot partitioning. It is possible to simplify further and move most of the native quicksort logic into Java. (One possible approach could be to modify the existing thresholds defined in DualPivotQuicksort.java.) Thank you once again for taking the time to review the changes. Regards, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1710889014 From duke at openjdk.org Fri Sep 8 00:00:16 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 00:00:16 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v12] In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: > [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.util.UUIDBench.toString" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) > > > > ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) > * cpu : aliyun yitian 710 (aarch64) > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) > > > ## 4. MacBookPro M1 Pro > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) > > > ## 5. Orange Pi 5 Plus > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us > > +Benchmark (size) Mode Cnt Score Error Units (PR) > +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) ??? has updated the pull request incrementally with one additional commit since the last revision: reversed how & hi ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14745/files - new: https://git.openjdk.org/jdk/pull/14745/files/2d36332b..747e8135 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=10-11 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14745/head:pull/14745 PR: https://git.openjdk.org/jdk/pull/14745 From psandoz at openjdk.org Fri Sep 8 00:01:50 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 8 Sep 2023 00:01:50 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v33] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 21:31:40 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: > > Change name of the avxsort library to libx86_64_sort Thank you for the summary. > Currently there is a regression of up to 20%, when the intrinsic is disabled. This has been root caused to two reasons: > > * performance loss due to using a generalized intrinsic for all data types (`int, long, float, double`) with multiple indirections and `switch()` in the fallback method implementation. > Ok, i cannot guarantee the fallback lambda approach does not regress :-) > * performance loss due to passing a `pivotIndices` array to the partition methods and modifying it in place. Passing the pivot indices explicitly to the partition method and then returning the updated pivot indices from the method as a new array is fixing this regression. > That's surprising, i wonder if that is related to the use of switch and somehow C2 cannot elide the allocation via escape analysis? One solution to avoid allocation is to pack the return of the two indices in a long value. That may also simplify the C2 intrinsic implementation. However, that restricts indices to int values. To support `MemorySegment` we need to support long value indices. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1710901803 From bpb at openjdk.org Fri Sep 8 01:07:17 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 8 Sep 2023 01:07:17 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v2] 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: Handle "\\?\UNC"; add bad paths to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15603/files - new: https://git.openjdk.org/jdk/pull/15603/files/0d4290cc..d9d84b8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=00-01 Stats: 16 lines in 2 files changed: 11 ins; 0 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 duke at openjdk.org Fri Sep 8 01:14:45 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 01:14:45 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote: > This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. > > This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: > > > Name Cnt Base Error Test Error Unit Diff% > HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) > :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) > :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 0,000 0,000 counts > HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) > :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) > :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) > :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) > :gc.count 15 0,000 0,000 ... Should we test the performance comparison of toHexDigits(long)? I've done some work before, and I didn't find a way to perform better than a lookup table without using a lookup table. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15591#issuecomment-1710944624 From duke at openjdk.org Fri Sep 8 02:16:54 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 02:16:54 GMT Subject: Integrated: 8310929: Optimization for Integer.toString In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Wed, 28 Jun 2023 17:06:56 GMT, ??? wrote: > Optimization for: > Integer.toString > Long.toString > StringBuilder#append(int) > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.lang.Integers.toString*" > make test TEST="micro:java.lang.Longs.toString*" > make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op > -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op > -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) > +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) > +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) > > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op > -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) > +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op > > +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) > > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op > -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op > -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op > > +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) > +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+34.09%) > +Integers.toStringSmall 500 avgt 15 3.491 ? 0.025 us/op (+28.04%) > +Integers.toStringTiny 5... This pull request has now been integrated. Changeset: 4b43c25f Author: shaojin.wensj Committer: Yi Yang URL: https://git.openjdk.org/jdk/commit/4b43c25fe382b5ee805a2d1b173fdd32d8da7fad Stats: 361 lines in 8 files changed: 189 ins; 146 del; 26 mod 8310929: Optimization for Integer.toString Reviewed-by: redestad, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/14699 From alanb at openjdk.org Fri Sep 8 05:36:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Sep 2023 05:36:54 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v33] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 21:31:40 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: > > Change name of the avxsort library to libx86_64_sort Would it be possible to provide a clear summary on why libx86_64_sort is being added? I'm trying to understand why these weren't linked into libjvm. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1711101611 From smarks at openjdk.org Fri Sep 8 06:26:39 2023 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 8 Sep 2023 06:26:39 GMT Subject: RFR: 8306632: Add a JDK Property for specifying DTD support In-Reply-To: References: Message-ID: <_OsL5CA2KQvBj743-Z-CTiThodkucW14lyC56pVIPnA=.bb398b8a-7b76-4f05-bd9e-cfe9734749cb@github.com> On Fri, 28 Jul 2023 18:41:48 GMT, Joe Wang wrote: > Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to specify how DTDs are handled. This property is uniformly supported across the JDK XML libraries. It complements, rather than replaces, the existing properties that are supportDTD for StAX and disallow-doctype-decl for DOM and SAX processors, which means the later will continue to work as they were and that if they are set, the new property will have no effect. Applications that use the existing properties continue to work as expected. > > This patch continues the path made previously with Xalan and XPath in which functions were moved into the jdk/xml classes. Similar changes are now made with the Xerces and XML classes, consolidating functions into the jdk/xml classes, reducing duplicate code for easier future maintenance. > > Tests: new tests are added to cover the various processors. > Existing tests pass. Only one was updated due to the change to the property impl. OK I looked through a bunch of the code and I didn't see anything that needs to be changed right now. However I did spot a number of issues for future work. :-) Good to see the duplicate XMLSecurityManager has been removed. However (not part of this diff) I note that there are two XMLSecurityPropertyManager classes in xerces and xalan. The code between them seems quite similar, so this might be an opportunity for future deduplication. Most of the logic around handling of properties and config settings looks like it's in jdk/xml/internal. There are bunches of enums here and String arrays indexed by enum ordinals, plus things that search the enum values() arrays. It seems like some things could be done to improve the internal representation of this information, both to reduce the amount of code, and to make things easier for clients of this information. It looks like ValueMapper1 is unused. In XMLDTDScannerImpl.java line 391 this line is inserted: fEntityScanner = fEntityManager.getEntityScanner(); The addition of this line kind of sticks out. The initial value of this field is null. This assignment is done repeatedly in a bunch of places; but other places just assume the field has been initialized. Was this an NPE, and are there possibilities of NPE in other code paths? I think the thing to do is to integrate this code as is, since it's already been tested, and then identify a few candidates for cleanup work. Then chip away at some cleanups in parallel with pursuing other design activities (e.g., Catalog). ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15075#pullrequestreview-1616760862 From mbaesken at openjdk.org Fri Sep 8 07:10:19 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 8 Sep 2023 07:10:19 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v5] In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: > We run into some BackingStoreException: Couldn't get file lock. e.g. here : > > [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120) > [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock. > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769) > [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864) > [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311) > [JShell] ... 4 more > > The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: remove unneeded empty line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15308/files - new: https://git.openjdk.org/jdk/pull/15308/files/b63064ec..5e3108b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15308&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15308&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15308.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15308/head:pull/15308 PR: https://git.openjdk.org/jdk/pull/15308 From mbaesken at openjdk.org Fri Sep 8 07:10:20 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 8 Sep 2023 07:10:20 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v4] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> <86maccfrzpjxVqqle-l3ZVAU9kadnS-_jSx-Dc9PZt8=.3ef956b6-8eee-4664-aab2-e676b37821bb@github.com> Message-ID: On Thu, 7 Sep 2023 14:28:47 GMT, Roger Riggs wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Use PrivilegedAction to get OS name > > src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 36: > >> 34: import sun.util.logging.PlatformLogger; >> 35: >> 36: > > Extra blank line. Hi Roger, I removed the line, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1319454172 From alanb at openjdk.org Fri Sep 8 07:22:42 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Sep 2023 07:22:42 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> Message-ID: <_b4wRbfmijSU1QL-bMrBvy5wQoaQp8fFO96SdOuE438=.923f52e6-b930-47c4-8e08-e7b299722657@github.com> On Mon, 4 Sep 2023 11:57:47 GMT, Matthias Baesken wrote: >>> Hi Alan , Your assumption 'I assume the use of System.getProperty is problematic when running with a SM.' is most likely correct. >> >> You'll need to test with a SM that denies reading the system property to be sure. There are classes in many tool APIs (you've listed some) where this doesn't arise. >> >> In any case, I assume this lookup will go away once you replace this method. > >> > Hi Alan , Your assumption 'I assume the use of System.getProperty is problematic when running with a SM.' is most likely correct. >> >> You'll need to test with a SM that denies reading the system property to be sure. There are classes in many tool APIs (you've listed some) where this doesn't arise. >> > > For > > java.management/share/classes/sun/management/VMManagementImpl.java > > I tried with a security manager and had to grant property access so that it worked properly. > > For > > java.desktop/share/classes/sun/awt/FontConfiguration.java > > this can be called from all code working with fonts so it needs to be handled too (e.g. PrivilegedAction). > > Should I file a JBS issue for those two ? > > > Some of the others listed might indeed fall into the tool APIs you mentioned. @MBaesken I don't think the changes in this PR should be integrated, we shouldn't be hardcoding the values of error numbers like this. Can you think again about the suggestion to replace the Unix implementation so that it uses FileChannel/Files? That should allow you to remove the native methods for locking and chmod. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1711197140 From mbaesken at openjdk.org Fri Sep 8 07:46:43 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 8 Sep 2023 07:46:43 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: <_b4wRbfmijSU1QL-bMrBvy5wQoaQp8fFO96SdOuE438=.923f52e6-b930-47c4-8e08-e7b299722657@github.com> References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> <_b4wRbfmijSU1QL-bMrBvy5wQoaQp8fFO96SdOuE438=.923f52e6-b930-47c4-8e08-e7b299722657@github.com> Message-ID: On Fri, 8 Sep 2023 07:19:55 GMT, Alan Bateman wrote: > we shouldn't be hardcoding the values of error numbers like this. Then print the good old int value and rely on OS tools to convert this, it is rather easy and available on some distros). Or move the current error-code handling code from nio to java.base (we have already coding for this in the JDK but cannot use it). > replace the Unix implementation so that it uses FileChannel/Files We could do this mid-term in some follow up action. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1711225903 From alanb at openjdk.org Fri Sep 8 08:06:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Sep 2023 08:06:41 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> <_b4wRbfmijSU1QL-bMrBvy5wQoaQp8fFO96SdOuE438=.923f52e6-b930-47c4-8e08-e7b299722657@github.com> Message-ID: On Fri, 8 Sep 2023 07:44:21 GMT, Matthias Baesken wrote: > We could do this mid-term in some follow up action. It shouldn't be hard to try it. If it works out then it would mean this old crufty code goes away and the JDK is in a better place. If it doesn't work out then the a plan B would be to add to have lockFile0 throw with a useful exception. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1711250512 From shade at openjdk.org Fri Sep 8 08:27:41 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Sep 2023 08:27:41 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:54:25 GMT, Martin Doerr wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Switch to PPC32 >> - Merge branch 'master' into JDK-8315578-ppc-builds >> - Fix > > Thanks! @TheRealMDoerr, PPC32 did not work out, see above. Still good to go in in current form? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15556#issuecomment-1711277313 From shade at openjdk.org Fri Sep 8 08:27:43 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Sep 2023 08:27:43 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v2] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 14:07:05 GMT, Roger Riggs wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Switch to PPC32 >> - Merge branch 'master' into JDK-8315578-ppc-builds >> - Fix > > src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 62: > >> 60: static final boolean TARGET_ARCH_IS_LOONGARCH64 = "@@OPENJDK_TARGET_CPU@@" == "loongarch64"; >> 61: static final boolean TARGET_ARCH_IS_S390 = "@@OPENJDK_TARGET_CPU@@" == "s390"; >> 62: static final boolean TARGET_ARCH_IS_PPC32 = "@@OPENJDK_TARGET_CPU@@" == "ppc"; > > The list is getting longer. I'd suggest/request that all the enums be resorted alphabetically. (now or later). Agreed, @RogerRiggs? If so, please approve. Aside, I am planning to bring the stack of relevant backports to 21u, to unbreak it there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15556#discussion_r1319536764 From mdoerr at openjdk.org Fri Sep 8 08:35:42 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 8 Sep 2023 08:35:42 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v3] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 16:21:18 GMT, Aleksey Shipilev wrote: >> Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Switch to PPC32" > > This reverts commit d829d243f94560dc19699d36b67a73280817b8f6. I can live with it. Hoping that not to many people get confused by `isPPC()` returning false on PPC64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15556#issuecomment-1711287961 From rgiulietti at openjdk.org Fri Sep 8 08:49:38 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 8 Sep 2023 08:49:38 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote: > This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. > > This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: > > > Name Cnt Base Error Test Error Unit Diff% > HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) > :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) > :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 0,000 0,000 counts > HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) > :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) > :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) > :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) > :gc.count 15 0,000 0,000 ... I'm not sure that micro-benchmarks are very indicative on whether a lookup table performs better than short and straightforward code. The reason is that, once in the CPU caches, a lookup table in micro-benchmarks stays there, whereas in more realistic situations, where access is more spread out in time, it is often evicted to make room for other, more lively data. A micro-benchmark using a lookup table shows good results because of a high rate of cache hits, whereas in other real-world workloads a lookup table might result in many cache misses on access. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15591#issuecomment-1711307164 From redestad at openjdk.org Fri Sep 8 09:36:43 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 8 Sep 2023 09:36:43 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 08:47:04 GMT, Raffaello Giulietti wrote: >> This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. >> >> This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: >> >> >> Name Cnt Base Error Test Error Unit Diff% >> HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) >> :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) >> :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 3,000 0,000 counts >> :gc.time 3 2,000 ms >> HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) >> :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) >> :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 3,000 0,000 counts >> :gc.time 3 2,000 ms >> HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) >> :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) >> :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 0,000 0,000 counts >> HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) >> :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) >> :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) >> :gc.count 15 3,000 0,000 counts >> :gc.time 3 2,000 ms >> HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) >> :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) >> :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) >> :gc.... > > I'm not sure that micro-benchmarks are very indicative on whether a lookup table performs better than short and straightforward code. > The reason is that, once in the CPU caches, a lookup table in micro-benchmarks stays there, whereas in more realistic situations, where access is more spread out in time, it is often evicted to make room for other, more lively data. > A micro-benchmark using a lookup table shows good results because of a high rate of cache hits, whereas in other real-world workloads a lookup table might result in many cache misses on access. As @rgiulietti says lookup-table algorithms may outperform in microbenchmarks but lose out in real world scenarios, so we need to stay clear unless there's major benefit. And as it turns out, the relative benefit seem to come mainly from the use of `ByteArrayLittleEndian`, not from using the lookup table in `HexDigits.DIGITS`: public String toHexDigits(byte value) { byte[] rep = new byte[2]; - rep[0] = (byte)toHighHexDigit(value); - rep[1] = (byte)toLowHexDigit(value); + ByteArrayLittleEndian.setChar(rep, 0, (char)(toHighHexDigit(value) << 8 | toLowHexDigit(value))); try { return jla.newStringNoRepl(rep, StandardCharsets.ISO_8859_1); } catch (CharacterCodingException cce) { This gets the same speed-up (4%) as calling `HexDigits.DIGITS`: Name Cnt Base Error Test Error Unit Diff% HexFormatBench.toHexDigits 15 1,943 ? 0,014 1,860 ? 0,014 us/op 4,2% (p = 0,000*) * = significant ------------- PR Comment: https://git.openjdk.org/jdk/pull/15591#issuecomment-1711370758 From alanb at openjdk.org Fri Sep 8 10:03:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Sep 2023 10:03:40 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v2] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 01:07:17 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: Handle "\\?\UNC"; add bad paths to test The two cases that I'm wondering about are `\?` and `\?\UNC`. For `\?` it looks like it will throw (you've got a test for that. I'm just wondering if there is input today where getParent().getCanonicalPath() would succeed today and fail wit hate change. For `\?\UNC` it looks it will be converted by the new code to `` so the root directory of the current volume, do I have that right? I'm trying to see how this case fails in the badPaths list. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1711407110 From asotona at openjdk.org Fri Sep 8 10:15:26 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 8 Sep 2023 10:15:26 GMT Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v13] In-Reply-To: References: Message-ID: > javap uses proprietary com.sun.tools.classfile library to parse class files. > > This patch converts javap to use Classfile API. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: applied suggested changes from review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11411/files - new: https://git.openjdk.org/jdk/pull/11411/files/697079f7..27ff5820 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=11-12 Stats: 14 lines in 2 files changed: 0 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411 PR: https://git.openjdk.org/jdk/pull/11411 From eliu at openjdk.org Fri Sep 8 10:15:42 2023 From: eliu at openjdk.org (Eric Liu) Date: Fri, 8 Sep 2023 10:15:42 GMT Subject: RFR: 8314544: Matrix multiple benchmark using Vector API [v2] In-Reply-To: References: Message-ID: <-rLgN6N2i-6m1h5VIE4ohcf6szWKMf1Uh5vNO8nKqrA=.edb4424b-c436-4c3d-823d-436df40c15ea@github.com> 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 Looks good to me. ------------- Marked as reviewed by eliu (Committer). PR Review: https://git.openjdk.org/jdk/pull/15338#pullrequestreview-1617144039 From asotona at openjdk.org Fri Sep 8 10:22:58 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 8 Sep 2023 10:22:58 GMT Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v11] In-Reply-To: References: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com> Message-ID: On Thu, 7 Sep 2023 03:10:33 GMT, Vicente Romero wrote: >> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits: >> >> - Merge branch 'master' into JDK-8294969-javap >> - Merge branch 'master' into JDK-8294969-javap >> - fixed code printing and ConstantPoolException reporting indoex >> - added DydnamicConstantPoolEntry::bootstrapMethodIndex >> fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute >> - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead >> - throwing ConstantPoolException for invalid BSM entry index >> - Merge branch 'master' into JDK-8294969-javap >> - fixed JavapTask >> - Merge branch 'master' into JDK-8294969-javap >> - Merge branch 'master' into JDK-8294969-javap >> >> # Conflicts: >> # src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java >> - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b > > src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 226: > >> 224: >> 225: /** >> 226: * {@return the field ref entry whose index is given at the specified > > I think that `ref` in these APIs should be `reference` fixed, thanks > src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java line 465: > >> 463: indent(+1); >> 464: print("target_platform: #" + attr.targetPlatform().index()); >> 465: //ToDo find the spec - can be null??? > > what about this comment? removed according to the available spec information > src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java line 549: > >> 547: case SourceIDAttribute attr -> >> 548: constantWriter.write(attr.sourceId().index()); >> 549: // case StackMapAttribute ??? > > I guess this comment can be removed removed, thanks > src/jdk.jdeps/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java line 46: > >> 44: * deletion without notice. >> 45: */ >> 46: public class LocalVariableTableWriter extends InstructionDetailWriter { > > nit: two spaces between `extends` and `InstructionDetailWriter` fixed, thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1319670807 PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1319669825 PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1319669976 PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1319671851 From asotona at openjdk.org Fri Sep 8 10:27:28 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 8 Sep 2023 10:27:28 GMT Subject: RFR: 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex methods are confusing [v3] In-Reply-To: References: Message-ID: > Classfile API `ConstantPool::entryCount` and `ConstantPool::entryByIndex` methods are confusing and unsafe to use without knowledge of constant pool specification. > This patch renames `ConstantPool::entryCount` to `ConstantPool::size` and adds checks to `ConstantPool::entryByIndex` for invalid or unusable indexes. > `ConstantPool` newly extends `Iterable` for simplified user iteration over all pool entries. > Range checks for invalid index have been added also to `ConstantPoo::bootstrapMethodEntry` methods and several `@jvms` javadoc tags have been added to pool entries. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base 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: - fixed javac tests - Merge branch 'master' into JDK-8315678-cp-iterable - fixed tests - 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex is confusing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15567/files - new: https://git.openjdk.org/jdk/pull/15567/files/38406b28..583b0315 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15567&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15567&range=01-02 Stats: 10641 lines in 417 files changed: 5586 ins; 2491 del; 2564 mod Patch: https://git.openjdk.org/jdk/pull/15567.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15567/head:pull/15567 PR: https://git.openjdk.org/jdk/pull/15567 From mcimadamore at openjdk.org Fri Sep 8 10:29:12 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 8 Sep 2023 10:29:12 GMT Subject: RFR: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" Message-ID: This PR adds a privileged block surrounding the request to load the fallback linker library in LibFallback. The lack of this block is causing test failures when platforms using the fallback linker are tested using a security manager. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk/pull/15633/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15633&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315891 Stats: 13 lines in 1 file changed: 6 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15633/head:pull/15633 PR: https://git.openjdk.org/jdk/pull/15633 From jvernee at openjdk.org Fri Sep 8 10:29:12 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 8 Sep 2023 10:29:12 GMT Subject: RFR: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 10:19:05 GMT, Maurizio Cimadamore wrote: > This PR adds a privileged block surrounding the request to load the fallback linker library in LibFallback. > The lack of this block is causing test failures when platforms using the fallback linker are tested using a security manager. src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 42: > 40: private static boolean tryLoadLibrary() { > 41: return java.security.AccessController.doPrivileged( > 42: new java.security.PrivilegedAction<>() { Could use imports instead of using fully qualified names here. src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 45: > 43: public Boolean run() { > 44: try { > 45: System.loadLibrary("jimage"); `"jimage"`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15633#discussion_r1319675039 PR Review Comment: https://git.openjdk.org/jdk/pull/15633#discussion_r1319674145 From redestad at openjdk.org Fri Sep 8 10:32:40 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 8 Sep 2023 10:32:40 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements [v2] In-Reply-To: References: Message-ID: > This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. > > This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: > > > Name Cnt Base Error Test Error Unit Diff% > HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) > :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) > :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 0,000 0,000 counts > HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) > :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) > :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) > :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) > :gc.count 15 0,000 0,000 ... Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add toHexDigitsByte|Short|Int|Long microbenchmarks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15591/files - new: https://git.openjdk.org/jdk/pull/15591/files/59a1f609..c2393766 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15591&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15591&range=00-01 Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15591/head:pull/15591 PR: https://git.openjdk.org/jdk/pull/15591 From redestad at openjdk.org Fri Sep 8 10:32:42 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 8 Sep 2023 10:32:42 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad wrote: > This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat. > > This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less: > > > Name Cnt Base Error Test Error Unit Diff% > HexFormatBench.appenderLower 15 1,330 ? 0,021 1,065 ? 0,067 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 11,481 ? 0,185 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderLowerCached 15 1,317 ? 0,013 1,065 ? 0,054 us/op 19,1% (p = 0,000*) > :gc.alloc.rate 15 11,590 ? 0,111 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.appenderUpper 15 1,330 ? 0,022 1,065 ? 0,036 us/op 19,9% (p = 0,000*) > :gc.alloc.rate 15 34,416 ? 0,559 0,007 ? 0,000 MB/sec -100,0% (p = 0,000*) > :gc.alloc.rate.norm 15 48,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 0,000 0,000 counts > HexFormatBench.appenderUpperCached 15 1,353 ? 0,009 1,033 ? 0,014 us/op 23,6% (p = 0,000*) > :gc.alloc.rate 15 11,284 ? 0,074 0,007 ? 0,000 MB/sec -99,9% (p = 0,000*) > :gc.alloc.rate.norm 15 16,009 ? 0,000 0,007 ? 0,000 B/op -100,0% (p = 0,000*) > :gc.count 15 3,000 0,000 counts > :gc.time 3 2,000 ms > HexFormatBench.toHexLower 15 0,198 ? 0,001 0,119 ? 0,008 us/op 40,1% (p = 0,000*) > :gc.alloc.rate 15 0,007 ? 0,000 0,007 ? 0,000 MB/sec -0,0% (p = 0,816 ) > :gc.alloc.rate.norm 15 0,001 ? 0,000 0,001 ? 0,000 B/op -40,1% (p = 0,000*) > :gc.count 15 0,000 0,000 ... I also tried variants of this for `toHexDigits(short|int|long)` but it always ends up worse. Both when chunking 2 digits at a time: ByteArrayLittleEndian.setChar(rep, 2, (char)(toHighHexDigit(value) << 8 | toLowHexDigit(value))); value >>= 8; ByteArrayLittleEndian.setChar(rep, 0, (char)(toHighHexDigit(value) << 8 | toLowHexDigit(value))); and when doing it all in one go (this code is `toHexDigits(short)`, which writes four nibbles): ByteArrayLittleEndian.setInt(rep, 0, toHighHexDigit(value >> 8) << 24 | toLowHexDigit(value >> 8) << 16 | toHighHexDigit(value) << 8 | toLowHexDigit(value))); Only a win on `toHexDigits(byte)`: Name Cnt Base Error Test Error Unit Diff% HexFormatBench.toHexDigitsByte 15 1,992 ? 0,008 1,908 ? 0,053 us/op 4,2% (p = 0,000*) HexFormatBench.toHexDigitsInt 15 2,476 ? 0,018 2,896 ? 0,023 us/op -16,9% (p = 0,000*) HexFormatBench.toHexDigitsLong 15 3,992 ? 0,052 4,229 ? 0,036 us/op -5,9% (p = 0,000*) HexFormatBench.toHexDigitsShort 15 2,183 ? 0,018 2,800 ? 0,162 us/op -28,3% (p = 0,000*) * = significant This is indicative that any win here comes from tickling the JIT the right way, rather than some intrinsic property of `ByteArrayLittleEndian`. I'll leave the code unchanged but add these microbenchmarks if anyone wants to attempt other improvements. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15591#issuecomment-1711436585 From duke at openjdk.org Fri Sep 8 10:42:23 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 10:42:23 GMT Subject: RFR: 8315585: Optimization for decimal to string [v6] In-Reply-To: References: Message-ID: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request with a new target base 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 optimization_for_decimal_to_string_2 - add testcase & bug fix - Merge branch 'master' into optimization_for_decimal_to_string - Merge branch 'master' into optimization_for_decimal_to_string - BigInteger use a separate jla - update copyright info - optimization for decimal to string ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/0c5833f4..df38b9d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=04-05 Stats: 8228 lines in 340 files changed: 4158 ins; 1745 del; 2325 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From mcimadamore at openjdk.org Fri Sep 8 10:52:06 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 8 Sep 2023 10:52:06 GMT Subject: RFR: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" [v2] In-Reply-To: References: Message-ID: > This PR adds a privileged block surrounding the request to load the fallback linker library in LibFallback. > The lack of this block is causing test failures when platforms using the fallback linker are tested using a security manager. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix library name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15633/files - new: https://git.openjdk.org/jdk/pull/15633/files/847a7461..e6d96918 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15633&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15633&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15633/head:pull/15633 PR: https://git.openjdk.org/jdk/pull/15633 From mcimadamore at openjdk.org Fri Sep 8 10:52:06 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 8 Sep 2023 10:52:06 GMT Subject: RFR: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" [v2] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 10:24:22 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix library name > > src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 42: > >> 40: private static boolean tryLoadLibrary() { >> 41: return java.security.AccessController.doPrivileged( >> 42: new java.security.PrivilegedAction<>() { > > Could use imports instead of using fully qualified names here. No - problem here is that AccessController is deprecated for removal - so if we import that, we'll get a warning on the import. > src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 45: > >> 43: public Boolean run() { >> 44: try { >> 45: System.loadLibrary("jimage"); > > `"jimage"`? whoops :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15633#discussion_r1319695373 PR Review Comment: https://git.openjdk.org/jdk/pull/15633#discussion_r1319694933 From sundar at openjdk.org Fri Sep 8 11:03:41 2023 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Fri, 8 Sep 2023 11:03:41 GMT Subject: RFR: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" [v2] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 10:52:06 GMT, Maurizio Cimadamore wrote: >> This PR adds a privileged block surrounding the request to load the fallback linker library in LibFallback. >> The lack of this block is causing test failures when platforms using the fallback linker are tested using a security manager. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix library name LGTM ------------- Marked as reviewed by sundar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15633#pullrequestreview-1617224151 From duke at openjdk.org Fri Sep 8 11:24:48 2023 From: duke at openjdk.org (ExE Boss) Date: Fri, 8 Sep 2023 11:24:48 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v16] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 13:07:50 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: > > Add support for sliced allocation src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 154: > 152: return UNSAFE.allocateMemory(size); > 153: } catch (IllegalArgumentException ex) { > 154: throw new OutOfMemoryError(); `OutOfMemoryError` should?be?updated to?have the?`Throwable`?accepting constructor?overloads, so?that this?can?include the?cause: Suggestion: throw new OutOfMemoryError(ex); See?also: https://github.com/openjdk/panama-foreign/pull/855#discussion_r1285058300 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1319732046 From jvernee at openjdk.org Fri Sep 8 11:26:41 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 8 Sep 2023 11:26:41 GMT Subject: RFR: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" [v2] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 10:52:06 GMT, Maurizio Cimadamore wrote: >> This PR adds a privileged block surrounding the request to load the fallback linker library in LibFallback. >> The lack of this block is causing test failures when platforms using the fallback linker are tested using a security manager. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix library name Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15633#pullrequestreview-1617262627 From duke at openjdk.org Fri Sep 8 12:00:17 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 12:00:17 GMT Subject: RFR: 8315585: Optimization for decimal to string [v7] In-Reply-To: References: Message-ID: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request incrementally with one additional commit since the last revision: Continue to optimize and reduce duplicate code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/df38b9d9..071acebf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=05-06 Stats: 814 lines in 7 files changed: 451 ins; 263 del; 100 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From duke at openjdk.org Fri Sep 8 12:06:41 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 12:06:41 GMT Subject: RFR: 8315585: Optimization for decimal to string [v3] In-Reply-To: <2pQ9OIOOwTXR7JKEDSNx8kC_7bVrgwoCoZPNcIAiuzk=.c3ffc4cc-7470-4b2a-900b-8a0a17de5955@github.com> References: <2pQ9OIOOwTXR7JKEDSNx8kC_7bVrgwoCoZPNcIAiuzk=.c3ffc4cc-7470-4b2a-900b-8a0a17de5955@github.com> Message-ID: On Tue, 5 Sep 2023 18:13:39 GMT, Claes Redestad wrote: >> ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into optimization_for_decimal_to_string >> - BigInteger use a separate jla >> - update copyright info >> - optimization for decimal to string > > I think there is way too much duplication of logic going on here, primarily with `StringLatin1.getChars(long, int, byte[])` (assuming #14699 is accepted in the current state where `Integer.getChars(int, int, byte[])` and `Long.getChars(...)` is moved there). Perhaps the bulk of this could be moved to `StringLatin1` and then exposed via e.g. `JavaLangAccess`. > > On the motivation side I think it'd be helpful if you could point to some larger benchmarks, frameworks et.c. where optimizing `BigDecimal::toString` makes a significant difference. There has been some recent optimizations that remove the need for `BigDecimal::toString` for some code paths, e.g., #9410 - does this alleviate the need for this optimization or is this still useful or even critical? @cl4es I have pushed a new commit to reduce duplicate code ------------- PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1711562590 From dl at openjdk.org Fri Sep 8 13:12:41 2023 From: dl at openjdk.org (Doug Lea) Date: Fri, 8 Sep 2023 13:12:41 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v26] In-Reply-To: References: Message-ID: <1gR09Yo64Q75qSxRO3TQsnAd3zL4Da8CSA2wyUBsBYA=.adbf6037-445c-47f9-9327-14e74f087cec@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 71 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8288899 - Use non-recursive tasks in close tests - Allow ThreadGroup access in tck tests - Avoid needing test threads - Merge branch 'openjdk:master' into JDK-8288899 - Avoid jtreg test group - Ignore more stray interrupts by test harness - Merge branch 'openjdk:master' into JDK-8288899 - Fix tests, undo workarounds - Avoid unwanted jtreg interrupts; undo unnecessary changes - ... and 61 more: https://git.openjdk.org/jdk/compare/427ca797...0eadfc73 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14301/files - new: https://git.openjdk.org/jdk/pull/14301/files/f2dd803e..0eadfc73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=24-25 Stats: 18245 lines in 637 files changed: 9984 ins; 5397 del; 2864 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 Sep 8 13:16:46 2023 From: dl at openjdk.org (Doug Lea) Date: Fri, 8 Sep 2023 13:16:46 GMT Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v25] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 08:46:09 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Allow ThreadGroup access in tck tests > > test/jdk/java/util/concurrent/tck/JSR166TestCase.java line 1687: > >> 1685: thread.join(timeoutMillis); >> 1686: break; >> 1687: } catch (InterruptedException ignore) { > > @DougLea Shouldn't this deduct the wait-time for the next join if it gets interrupted? ? Ordinarily yes, but here it shouldn't matter: the timeout is just an arbitrary value to catch stuck tests, and sometimes waiting twice as long because of an interrupt is OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1319856505 From duke at openjdk.org Fri Sep 8 14:08:39 2023 From: duke at openjdk.org (iaroslavski) Date: Fri, 8 Sep 2023 14:08:39 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> Message-ID: On Fri, 1 Sep 2023 06:12:57 GMT, Alan Bateman wrote: >> Hi team, >> @AlanBateman, @rose00, @mbreinhold >> >> There are a big efforts now to improve sorting with x86_64 AVX512 >> https://github.com/openjdk/jdk/pull/14227, no changes of >> Dual-Pivot Quicksort logic. >> >> But at the same time this PR offers algorithmic improvements, >> like optimized insertion sort, merging sort, better partitioning >> and Radix sort for fully random data. Radix sort has linear complexity >> instead of n*ln(n), much faster!. Also we handle properly situation if >> no enough memory for additional buffer, now we will face with OOM. >> >> Alan, you mentioned that DualPivotQuicksort will need detailed review. >> Can we go ahead and start reviewing? Laurent checked performance, >> JMH results look fine. >> >> I think it would be logical to integrate new DualPivotQuicksort first, >> and then apply AVX512 changes. > >> 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. Hi Alan (@AlanBateman) and team, I understand your doubts about Radix sort, let's me to provide my thoughts. Code of Radix sort is about 10% of all code and very clear for understanding: scan digits + then place elements according histogram. Other sorting algorithms have more complexity (like merging sort, quicksort partitioning, heap sort). Therefore, I don't expect problems with maintaining. Why Radix sort is important? Even Quicksort is very fast, but it relies on comparability of elements only and knows nothing about nature of elements to be sorted. Radix sort knows the structure of elements (32 or 64 bits) and therefore works faster (on random data). I was asked many times why we don't use Radix sort, so the idea is not new. Introducing of Radix sort is like using of counting sort for byte/short/char, the same approach. Existing version of sort() will request additional memory, if tryMergingSort() detects already sorted subsequences. In this case Radix sort or Quicksort will not be invoked at all. Radix sort is invoked, if merging sort is not completed (and therefore, no allocated memory). Additional memory is requested by either merging sort or Radix sort, not by both algorithms on the same input. It means these algorithms never request double memory. Memory effect (merging sort and Radix sort) is not summarized. In case of parallel sorting the additional buffer allocated for parallel merge sort will be reused by tryMergingSort() as well as by Radix sort. **Summary:** the size of total requested memory always equals to the size of part to be sorted (not more), no any duplicates. Need to say that Radix sort is invoked not on all inputs, many inputs are covered by Quicksort or merging sort. If Quicksort suggests O(n*ln(n)), Radix sort shows linear, much better, O(n) time! As it was mentioned before, we added check against OOM, sorting will be completed successfully in any case. Existing implementation will fail with error, if there is no enough memory. **In few words,** Radix sort is simple and it impacts not more than already introduced algorithms in JDK. I encourage reviewers to look at this PR. Thank you, Vladimir ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1711730647 From dfuchs at openjdk.org Fri Sep 8 14:24:38 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 8 Sep 2023 14:24:38 GMT Subject: RFR: 8315696: SignedLoggerFinderTest.java test failed In-Reply-To: <2Z7k7CgJemfnuEvZApN87RpMEO34MTN2a7YUxDSL_tc=.f1b92993-1742-4d92-be8c-5c8944a51191@github.com> References: <2Z7k7CgJemfnuEvZApN87RpMEO34MTN2a7YUxDSL_tc=.f1b92993-1742-4d92-be8c-5c8944a51191@github.com> Message-ID: On Tue, 5 Sep 2023 20:06:41 GMT, Sean Coffey wrote: > Update the recently added LoggerFinder tests to cater for a possible condition where the test finishes before the boot logger executor service has flushed its pending data. > > By simulating a slow thread in the ExecutorService used in BootstrapLogger, I was able to reproduce the issue described. Adding the `BootstrapLoggerUtils.awaitPending();` call allows the tests to pass. LGTM! Thanks for the update Se?n. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15571#pullrequestreview-1617603386 From coffeys at openjdk.org Fri Sep 8 14:28:52 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 8 Sep 2023 14:28:52 GMT Subject: Integrated: 8315696: SignedLoggerFinderTest.java test failed In-Reply-To: <2Z7k7CgJemfnuEvZApN87RpMEO34MTN2a7YUxDSL_tc=.f1b92993-1742-4d92-be8c-5c8944a51191@github.com> References: <2Z7k7CgJemfnuEvZApN87RpMEO34MTN2a7YUxDSL_tc=.f1b92993-1742-4d92-be8c-5c8944a51191@github.com> Message-ID: On Tue, 5 Sep 2023 20:06:41 GMT, Sean Coffey wrote: > Update the recently added LoggerFinder tests to cater for a possible condition where the test finishes before the boot logger executor service has flushed its pending data. > > By simulating a slow thread in the ExecutorService used in BootstrapLogger, I was able to reproduce the issue described. Adding the `BootstrapLoggerUtils.awaitPending();` call allows the tests to pass. This pull request has now been integrated. Changeset: e409d07a Author: Sean Coffey URL: https://git.openjdk.org/jdk/commit/e409d07ae84c693b656c02befb636593f9293635 Stats: 147 lines in 8 files changed: 74 ins; 64 del; 9 mod 8315696: SignedLoggerFinderTest.java test failed Co-authored-by: Daniel Fuchs Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/15571 From jvernee at openjdk.org Fri Sep 8 14:35:25 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 8 Sep 2023 14:35:25 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v19] 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 41 commits: - Merge branch 'master' into JEP22 - add code snippet - Split long throws clauses in `MemorySegment` javadoc Reviewed-by: jvernee - Add support for sliced allocation - add name of SysV ABI - Fix javadoc issues in MemorySegment::copy Reviewed-by: jvernee - remove reference to allocateArray - PPC linker changes - Merge branch 'master' into JEP22 - Paul's review comments - ... and 31 more: https://git.openjdk.org/jdk/compare/e409d07a...dbf3eec6 ------------- Changes: https://git.openjdk.org/jdk/pull/15103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=18 Stats: 3753 lines in 244 files changed: 1897 ins; 1000 del; 856 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 Sep 8 14:40:47 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 8 Sep 2023 14:40:47 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v16] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 11:20:39 GMT, ExE Boss wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Add support for sliced allocation > > src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 154: > >> 152: return UNSAFE.allocateMemory(size); >> 153: } catch (IllegalArgumentException ex) { >> 154: throw new OutOfMemoryError(); > > `OutOfMemoryError` should?be?updated to?have the?`Throwable`?accepting constructor?overloads, so?that this?can?include the?cause: > Suggestion: > > throw new OutOfMemoryError(ex); > > > See?also: https://github.com/openjdk/panama-foreign/pull/855#discussion_r1285058300 I think enhancing `OutOfMemoryError` is a discussion to be had separately. Not as a part of this JEP. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1319957862 From naoto at openjdk.org Fri Sep 8 14:46:48 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 8 Sep 2023 14:46:48 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v14] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 16:57:20 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporating suggested changes > > src/java.base/share/classes/java/text/ListFormat.java line 95: > >> 93: * On parsing, if some ambiguity is found in the input string, such as delimiting >> 94: * sequences being found in the input string, may produce the result that when formatted is not a >> 95: * round-trip with the corresponding formatting. For example, a two element String list > > Suggestion: > > * On parsing, if some ambiguity is found in the input string, such as delimiting > * sequences in the input string, the result, when formatted with the same formatting, does not > * re-produce the input string . For example, a two element String list Thanks, Roger. Incorporated. > src/java.base/share/classes/java/text/ListFormat.java line 345: > >> 343: * of Object. >> 344: * @param toAppendTo where the text is to be appended >> 345: * @param pos Ignored. Not used in ListFormat. May be null > > Curious, why not used? > I could see a use to identity the string inserted to enable highlighting or other markup around the new string. `FieldPosition` is dedicated to identifying fields in *Format classes which are either `Format.Field` or fields that have names ending with "_FIELD", which ListFormat has neither of them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1318969734 PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1318969680 From rriggs at openjdk.org Fri Sep 8 14:46:54 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Sep 2023 14:46:54 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v15] In-Reply-To: References: Message-ID: <75ndrilVt0qdL2-a8T3JZmsTeLVItTxCNN51UVEwnzA=.d9c2f952-98b1-46e0-9a1b-f241f6eb1963@github.com> On Thu, 7 Sep 2023 18:20:28 GMT, Naoto Sato wrote: >> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision: > > - Reflects review comments > - Merge branch 'master' into JDK-8041488-ListPatterns-PR > - Incorporating suggested changes > - Update src/java.base/share/classes/java/text/ListFormat.java > > Co-authored-by: Roger Riggs > - Update src/java.base/share/classes/java/text/ListFormat.java > > Co-authored-by: Roger Riggs > - Update src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java > > Co-authored-by: Roger Riggs > - Removing unnecessary commas > - Added tests > - Review comments > - Merge branch 'master' into JDK-8041488-ListPatterns-PR > - ... and 14 more: https://git.openjdk.org/jdk/compare/5793a5da...bce82a4f src/java.base/share/classes/java/text/ListFormat.java line 536: > 534: try { > 535: init(); > 536: } catch (IllegalArgumentException iae) { If the `patterns` array contains a null, perhaps due to corrupted stream contents, `init()` will throw NPE. I don't recommend catching NPE here, but perhaps `init()` should check for nulls and throw IAE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1319965477 From rriggs at openjdk.org Fri Sep 8 14:49:40 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Sep 2023 14:49:40 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v3] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 16:21:18 GMT, Aleksey Shipilev wrote: >> Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Switch to PPC32" > > This reverts commit d829d243f94560dc19699d36b67a73280817b8f6. Looks ok with PPC == PPC 32 ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15556#pullrequestreview-1617656339 From redestad at openjdk.org Fri Sep 8 14:52:42 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 8 Sep 2023 14:52:42 GMT Subject: RFR: 8315585: Optimization for decimal to string [v7] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 12:00:17 GMT, ??? wrote: >> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. >> >> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. >> >> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. >> >> The performance data is as follows: >> >> ## 1. benchmark script >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.math.BigDecimals.*ToPlainString" >> make test TEST="micro:java.math.BigDecimals.*ToEngineering" >> >> >> ## 2. benchmark environment >> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) >> * cpu intel xeon sapphire rapids (x64) >> >> ## 3. benchmark result >> >> -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) >> -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op >> -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op >> -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) >> +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) >> +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) >> +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op >> -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op >> -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op >> -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) >> +BigDecimals.testLargeToEngineeringStr... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > Continue to optimize and reduce duplicate code 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. src/java.base/share/classes/java/lang/String.java line 699: > 697: } > 698: > 699: static String newStringLatin1NoRepl(byte[] bytes) { How much does this help compared to calling `jla.newStringNoRepl(bytes, StandardCharsets.ISO_8859_1)`? Maybe something that would be better split out to a separate enhancement and examined in isolation and apply it in other places where applicable (`java.util.UUID`, `java.util.HexFormat`) src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 358: > 356: > 357: /** > 358: * Pack the two ascii characters corresponding to the value from 0 to 100 into a short Wording and name of this method can be improved. Suggestion: `short digitPair(int i)` "For values from 0 to 99 return a `short` encoding a pair of ASCII-encoded digit characters in little-endian, e.g. `0 -> ('0' << 8 | '0')`. Used for formatting." ------------- PR Review: https://git.openjdk.org/jdk/pull/15555#pullrequestreview-1617373581 PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1319803899 PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1319939577 From dfuchs at openjdk.org Fri Sep 8 15:02:41 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 8 Sep 2023 15:02:41 GMT Subject: RFR: 8277954: Replace use of monitors with explicit locks in the JDK LDAP provider implementation In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 22:48:30 GMT, Aleksei Efimov wrote: > The change proposed in this PR improves the behavior of the JDK JNDI/LDAP provider when running in a virtual thread. Currently, when an LDAP operation is performed from a virtual thread context a pinned carrier thread is detected: > > Thread[#29,ForkJoinPool-1-worker-1,5,CarrierThreads] > java.naming/com.sun.jndi.ldap.Connection.read reply(Connection.java:444) <== monitors:1 > java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:369) <== monitors:1 > java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:196) <== monitors:1 > java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2896) <== monitors:1 > > To fix that monitor usages are replaced with `j.u.c` locks. All synchronized blocks/methods have been replaced with locks even if it is only guarding memory access - the motivation behind such a decision was to avoid an analysis of scenarios where a mix of monitors and `j.u.c` locks is used. > > There are three types of mechanical changes done in this PR: > > 1. Classes with `synchronized` blocks or `synchronized` methods have been updated to include a new `ReentrantLock` field. These new fields are used to replace `synchronized` blocks/methods. > 1. classes that use notify/wait on object monitor have been updated to use `ReentrantLock.Condition`s signal/await. > 1. if one class `synchronized` on an instance of another class - the `ReentrantLock` added in item (1) was made a package-protected to give access to another class. > > With the proposed changes pinned carrier threads are no longer detected during execution of LDAP operations. > > Testing: `jdk-tier1` to `jdk-tier3`, other `jndi/ldap` regression and JCK naming tests show no failures. Look reasonable to me. If tier2 and all jndi tests are still passing, I'm good with it. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15526#pullrequestreview-1617680805 From alanb at openjdk.org Fri Sep 8 15:09:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Sep 2023 15:09:09 GMT Subject: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v4] In-Reply-To: References: Message-ID: <8I7_5llQ2VBB3eJ4IoFjPXR0Rb8Mf1-pTlVFmvNgT_s=.fa7dd70d-d0c3-4e96-9eac-16432b3297de@github.com> > In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM. > > The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition. > > Testing: tier1-5 Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Drop changes to sampler, move transition check to JfrThreadLocal::is_vthread - Merge - Restore @ChangesCurrentThread to run(Runnable) - Move transition check to JfrVframeStream ctor - Merge - Check for transition during stack walk for synchronous case - Merge - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15492/files - new: https://git.openjdk.org/jdk/pull/15492/files/507ae919..309dddf2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15492&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15492&range=02-03 Stats: 8630 lines in 351 files changed: 4519 ins; 1766 del; 2345 mod Patch: https://git.openjdk.org/jdk/pull/15492.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15492/head:pull/15492 PR: https://git.openjdk.org/jdk/pull/15492 From shade at openjdk.org Fri Sep 8 15:11:43 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Sep 2023 15:11:43 GMT Subject: RFR: 8315578: PPC builds are broken after JDK-8304913 [v3] In-Reply-To: References: Message-ID: On Thu, 7 Sep 2023 16:21:18 GMT, Aleksey Shipilev wrote: >> Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Switch to PPC32" > > This reverts commit d829d243f94560dc19699d36b67a73280817b8f6. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15556#issuecomment-1711822730 From shade at openjdk.org Fri Sep 8 15:14:49 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Sep 2023 15:14:49 GMT Subject: Integrated: 8315578: PPC builds are broken after JDK-8304913 In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 07:26:37 GMT, Aleksey Shipilev wrote: > Similar to other issues in the same area. I have no PPC32 machine to test the build on, but this matches other fixes for other architectures (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb) after this fix the PPC32 Zero build completes fine. This pull request has now been integrated. Changeset: 9559e035 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/9559e035d2692d9d61bec2a13b5239a98db077ac Stats: 12 lines in 3 files changed: 12 ins; 0 del; 0 mod 8315578: PPC builds are broken after JDK-8304913 Reviewed-by: mdoerr, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/15556 From rriggs at openjdk.org Fri Sep 8 15:28:53 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Sep 2023 15:28:53 GMT Subject: RFR: 8310929: Optimization for Integer.toString [v21] In-Reply-To: References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com> Message-ID: On Wed, 6 Sep 2023 22:22:12 GMT, ??? wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.lang.Integers.toString*" >> make test TEST="micro:java.lang.Longs.toString*" >> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.825 ? 0.023 us/op >> -Integers.toStringSmall 500 avgt 15 4.823 ? 0.023 us/op >> -Integers.toStringTiny 500 avgt 15 3.878 ? 0.101 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 6.002 ? 0.054 us/op (+13.71%) >> +Integers.toStringSmall 500 avgt 15 4.025 ? 0.020 us/op (+19.82%) >> +Integers.toStringTiny 500 avgt 15 3.874 ? 0.067 us/op (+0.10%) >> >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Longs.toStringBig 500 avgt 15 9.224 ? 0.021 us/op >> -Longs.toStringSmall 500 avgt 15 4.621 ? 0.087 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Longs.toStringBig 500 avgt 15 7.483 ? 0.018 us/op (+23.26%) >> +Longs.toStringSmall 500 avgt 15 4.020 ? 0.016 us/op (+14.95%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -StringBuilders.toStringCharWithInt8 avgt 15 89.327 ? 0.733 ns/op >> >> +Benchmark Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +StringBuilders.toStringCharWithInt8 avgt 15 36.639 ? 0.422 ns/op (+143.80%) >> >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -Integers.toStringBig 500 avgt 15 6.753 ? 0.007 us/op >> -Integers.toStringSmall 500 avgt 15 4.470 ? 0.005 us/op >> -Integers.toStringTiny 500 avgt 15 2.764 ? 0.020 us/op >> >> +Benchmark (size) Mode Cnt Score Error Units (PR Update 04 f4aa1989) >> +Integers.toStringBig 500 avgt 15 5.036 ? 0.005 us/op (+... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > use ByteArrayLittleEndian > /backport jdk21u fyi, the backport command is issued on the final commit (not the PR). So that https://github.com/openjdk/jdk/commit/4b43c25fe382b5ee805a2d1b173fdd32d8da7fad from the bot message above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1711846001 From bpb at openjdk.org Fri Sep 8 15:31:42 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 8 Sep 2023 15:31:42 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v2] In-Reply-To: References: Message-ID: <2ClIeIWA8p4dYJgwr9Jdnex1rkbnAkrUcd9liqH1MKY=.7cd678c9-6059-46ae-bb25-f7ebceb3e8df@github.com> On Fri, 8 Sep 2023 10:00:42 GMT, Alan Bateman wrote: > I'm trying to see how this case fails in the badPaths list. I'll investigate the other topics you raise, but I should point out that the results of this test are the same as for the mainline except for the last two good paths list.add(Arguments.of("\\\?\\C:\\Users\\file.dat", "C:\\Users\\file.dat")); list.add(Arguments.of("\\\?\\UNC\\localhost\\C$\\Users\\file.dat", "\\\\localhost\\C$\\Users\\file.dat")); which fail with the mainline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1711849577 From duke at openjdk.org Fri Sep 8 15:36:48 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 15:36:48 GMT Subject: RFR: 8315585: Optimization for decimal to string [v7] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 12:25:02 GMT, Claes Redestad wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> Continue to optimize and reduce duplicate code > > src/java.base/share/classes/java/lang/String.java line 699: > >> 697: } >> 698: >> 699: static String newStringLatin1NoRepl(byte[] bytes) { > > How much does this help compared to calling `jla.newStringNoRepl(bytes, StandardCharsets.ISO_8859_1)`? Maybe something that would be better split out to a separate enhancement and examined in isolation and apply it in other places where applicable (`java.util.UUID`, `java.util.HexFormat`) newStringLatin1NoRepl does not significantly help performance, but it simplifies the code. Of course, there is another advantage: because the call will be simpler, making it easier for the caller method to implement codeSize smaller than the default value of FreqInlineSize 325, and there are more opportunities to be inlined. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1320022640 From shade at openjdk.org Fri Sep 8 15:37:58 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Sep 2023 15:37:58 GMT Subject: RFR: 8315942: Sort platform enums and definitions after JDK-8304913 follow-ups Message-ID: @RogerRiggs asked for this. The moves are mechanical, so nothing should be lost. Tell me if other things need to be sorted as well. I would wait a little to see if there are any more JDK-8304913 followups. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/15640/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15640&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315942 Stats: 29 lines in 3 files changed: 12 ins; 11 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15640.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15640/head:pull/15640 PR: https://git.openjdk.org/jdk/pull/15640 From liach at openjdk.org Fri Sep 8 15:44:41 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 8 Sep 2023 15:44:41 GMT Subject: RFR: 8315585: Optimization for decimal to string [v7] In-Reply-To: References: Message-ID: <7Qzi4prSgdVv-yZZ-SLubHrXd1taOsuVKAEwRUPSiH0=.f91d9d83-2893-4cf5-a8bc-32b9ab9f2642@github.com> On Fri, 8 Sep 2023 15:34:16 GMT, ??? wrote: >> src/java.base/share/classes/java/lang/String.java line 699: >> >>> 697: } >>> 698: >>> 699: static String newStringLatin1NoRepl(byte[] bytes) { >> >> How much does this help compared to calling `jla.newStringNoRepl(bytes, StandardCharsets.ISO_8859_1)`? Maybe something that would be better split out to a separate enhancement and examined in isolation and apply it in other places where applicable (`java.util.UUID`, `java.util.HexFormat`) > > newStringLatin1NoRepl does not significantly help performance, but it simplifies the code. > > Of course, there is another advantage: because the call will be simpler, making it easier for the caller method to implement codeSize smaller than the default value of FreqInlineSize 325, and there are more opportunities to be inlined. Notice there is patch https://github.com/openjdk/jdk/pull/14655 (bug 8310901) for converting these usages to a new `newStringLatin1NoRepl`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1320028073 From redestad at openjdk.org Fri Sep 8 15:44:42 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 8 Sep 2023 15:44:42 GMT Subject: RFR: 8315585: Optimization for decimal to string [v7] In-Reply-To: <7Qzi4prSgdVv-yZZ-SLubHrXd1taOsuVKAEwRUPSiH0=.f91d9d83-2893-4cf5-a8bc-32b9ab9f2642@github.com> References: <7Qzi4prSgdVv-yZZ-SLubHrXd1taOsuVKAEwRUPSiH0=.f91d9d83-2893-4cf5-a8bc-32b9ab9f2642@github.com> Message-ID: On Fri, 8 Sep 2023 15:39:47 GMT, Chen Liang wrote: >> newStringLatin1NoRepl does not significantly help performance, but it simplifies the code. >> >> Of course, there is another advantage: because the call will be simpler, making it easier for the caller method to implement codeSize smaller than the default value of FreqInlineSize 325, and there are more opportunities to be inlined. > > Notice there is patch https://github.com/openjdk/jdk/pull/14655 (bug 8310901) for converting these usages to a new `newStringLatin1NoRepl`. Going from `jla.newStringNoRepl(bytes, ISO_...)` to `jla.newStringLatin1NoRepl(bytes)` isn't much of a code simplification, so this distracts a bit from the bulk of the changes in this PR. I agree that it *might* help inlining since the former calls into a large method, but I think we ought to focus on one thing at a time so if this doesn't significantly help on the benchmarks we have available it would be better to leave it out for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1320030130 From redestad at openjdk.org Fri Sep 8 15:51:40 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 8 Sep 2023 15:51:40 GMT Subject: RFR: 8315585: Optimization for decimal to string [v7] In-Reply-To: References: <7Qzi4prSgdVv-yZZ-SLubHrXd1taOsuVKAEwRUPSiH0=.f91d9d83-2893-4cf5-a8bc-32b9ab9f2642@github.com> Message-ID: On Fri, 8 Sep 2023 15:41:41 GMT, Claes Redestad wrote: >> Notice there is patch https://github.com/openjdk/jdk/pull/14655 (bug 8310901) for converting these usages to a new `newStringLatin1NoRepl`. > > Going from `jla.newStringNoRepl(bytes, ISO_...)` to `jla.newStringLatin1NoRepl(bytes)` isn't much of a code simplification, so this distracts a bit from the bulk of the changes in this PR. I agree that it *might* help inlining since the former calls into a large method, but I think we ought to focus on one thing at a time so if this doesn't significantly help on the benchmarks we have available it would be better to leave it out for now. I'll have a look at #14655 though I note that @RogerRiggs has already commented that this might not carry its own weight. These internal API bridges are a nuisance so we need to take care to make sure that any addition is actually necessary, not just convenient for the time being. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1320037600 From duke at openjdk.org Fri Sep 8 16:03:14 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 16:03:14 GMT Subject: RFR: 8315585: Optimization for decimal to string [v8] In-Reply-To: References: Message-ID: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request incrementally with two additional commits since the last revision: - rename jla.digit to digitPair - fix adjusted >= Integer.MAX_VALUE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/071acebf..ee3dd950 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=06-07 Stats: 9 lines in 4 files changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From pminborg at openjdk.org Fri Sep 8 16:13:16 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 8 Sep 2023 16:13:16 GMT Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes [v3] In-Reply-To: References: Message-ID: > This PR proposes to slightly improve some iterators of `AbstractMap`: > > * Code reuse > * A field declared `final` > * Add missing `@Override` annotations 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15615/files - new: https://git.openjdk.org/jdk/pull/15615/files/aab2472a..1057e166 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15615&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15615&range=01-02 Stats: 30 lines in 1 file changed: 0 ins; 17 del; 13 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 rriggs at openjdk.org Fri Sep 8 16:13:44 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Sep 2023 16:13:44 GMT Subject: RFR: 8315942: Sort platform enums and definitions after JDK-8304913 follow-ups In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 15:31:02 GMT, Aleksey Shipilev wrote: > @RogerRiggs asked for this. The moves are mechanical, so nothing should be lost. Tell me if other things need to be sorted as well. > > I would wait a little to see if there are any more JDK-8304913 followups. LGTM, thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15640#pullrequestreview-1617813671 From duke at openjdk.org Fri Sep 8 16:13:45 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 16:13:45 GMT Subject: RFR: 8315585: Optimization for decimal to string [v7] In-Reply-To: References: <7Qzi4prSgdVv-yZZ-SLubHrXd1taOsuVKAEwRUPSiH0=.f91d9d83-2893-4cf5-a8bc-32b9ab9f2642@github.com> Message-ID: On Fri, 8 Sep 2023 15:48:55 GMT, Claes Redestad wrote: >> Going from `jla.newStringNoRepl(bytes, ISO_...)` to `jla.newStringLatin1NoRepl(bytes)` isn't much of a code simplification, so this distracts a bit from the bulk of the changes in this PR. I agree that it *might* help inlining since the former calls into a large method, but I think we ought to focus on one thing at a time so if this doesn't significantly help on the benchmarks we have available it would be better to leave it out for now. > > I'll have a look at #14655 though I note that @RogerRiggs has already commented that this might not carry its own weight. These internal API bridges are a nuisance so we need to take care to make sure that any addition is actually necessary, not just convenient for the time being. Can you help me create an issue for jla.newStringNoRepl? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1320063049 From dcubed at openjdk.org Fri Sep 8 16:20:40 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 8 Sep 2023 16:20:40 GMT Subject: RFR: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" [v2] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 10:52:06 GMT, Maurizio Cimadamore wrote: >> This PR adds a privileged block surrounding the request to load the fallback linker library in LibFallback. >> The lack of this block is causing test failures when platforms using the fallback linker are tested using a security manager. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix library name @mcimadamore - are you planning to integrate this fix soon? This failure happens in every Tier5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15633#issuecomment-1711922411 From rriggs at openjdk.org Fri Sep 8 16:28:39 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Sep 2023 16:28:39 GMT Subject: RFR: 8315585: Optimization for decimal to string [v7] In-Reply-To: References: <7Qzi4prSgdVv-yZZ-SLubHrXd1taOsuVKAEwRUPSiH0=.f91d9d83-2893-4cf5-a8bc-32b9ab9f2642@github.com> Message-ID: <1d_Syh-gpKsELKTluPvdGTnifqnWf382gvZuTt4LCIk=.947795e4-8ff5-4f72-a02d-3a1fd8b51a07@github.com> On Fri, 8 Sep 2023 15:48:55 GMT, Claes Redestad wrote: >> Going from `jla.newStringNoRepl(bytes, ISO_...)` to `jla.newStringLatin1NoRepl(bytes)` isn't much of a code simplification, so this distracts a bit from the bulk of the changes in this PR. I agree that it *might* help inlining since the former calls into a large method, but I think we ought to focus on one thing at a time so if this doesn't significantly help on the benchmarks we have available it would be better to leave it out for now. > > I'll have a look at #14655 though I note that @RogerRiggs has already commented that this might not carry its own weight. These internal API bridges are a nuisance so we need to take care to make sure that any addition is actually necessary, not just convenient for the time being. I've recommended before to not add this convenience method, there's quite enough stuff in shared secrets and adds function that is too close to one already there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1320079180 From pminborg at openjdk.org Fri Sep 8 16:34:39 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 8 Sep 2023 16:34:39 GMT Subject: RFR: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" [v2] In-Reply-To: References: Message-ID: <7DoNrz81ykDyBE2rQYq4-jpb7tOQX-v3mkcoGxZpnhM=.a8df3698-f841-4506-8c4a-0efa7ca33fba@github.com> On Fri, 8 Sep 2023 10:52:06 GMT, Maurizio Cimadamore wrote: >> This PR adds a privileged block surrounding the request to load the fallback linker library in LibFallback. >> The lack of this block is causing test failures when platforms using the fallback linker are tested using a security manager. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix library name Looks good! ------------- Marked as reviewed by pminborg (Committer). PR Review: https://git.openjdk.org/jdk/pull/15633#pullrequestreview-1617853433 From mcimadamore at openjdk.org Fri Sep 8 16:39:51 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 8 Sep 2023 16:39:51 GMT Subject: Integrated: 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 10:19:05 GMT, Maurizio Cimadamore wrote: > This PR adds a privileged block surrounding the request to load the fallback linker library in LibFallback. > The lack of this block is causing test failures when platforms using the fallback linker are tested using a security manager. This pull request has now been integrated. Changeset: a62c48b8 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/a62c48b87e814b5b1f4c8089f9ff354156f92f69 Stats: 13 lines in 1 file changed: 6 ins; 0 del; 7 mod 8315891: java/foreign/TestLinker.java failed with "error occurred while instantiating class TestLinker: null" Reviewed-by: sundar, jvernee, pminborg ------------- PR: https://git.openjdk.org/jdk/pull/15633 From joehw at openjdk.org Fri Sep 8 16:44:31 2023 From: joehw at openjdk.org (Joe Wang) Date: Fri, 8 Sep 2023 16:44:31 GMT Subject: RFR: 8306632: Add a JDK Property for specifying DTD support [v2] In-Reply-To: References: Message-ID: > Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to specify how DTDs are handled. This property is uniformly supported across the JDK XML libraries. It complements, rather than replaces, the existing properties that are supportDTD for StAX and disallow-doctype-decl for DOM and SAX processors, which means the later will continue to work as they were and that if they are set, the new property will have no effect. Applications that use the existing properties continue to work as expected. > > This patch continues the path made previously with Xalan and XPath in which functions were moved into the jdk/xml classes. Similar changes are now made with the Xerces and XML classes, consolidating functions into the jdk/xml classes, reducing duplicate code for easier future maintenance. > > Tests: new tests are added to cover the various processors. > Existing tests pass. Only one was updated due to the change to the property impl. 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8306632 Sync up to re-run tests. - fix Whitespace errors - 8306632: Add a JDK Property for specifying DTD support ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15075/files - new: https://git.openjdk.org/jdk/pull/15075/files/ce6cf352..b9877b15 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15075&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15075&range=00-01 Stats: 68159 lines in 2227 files changed: 38336 ins; 14910 del; 14913 mod Patch: https://git.openjdk.org/jdk/pull/15075.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15075/head:pull/15075 PR: https://git.openjdk.org/jdk/pull/15075 From joehw at openjdk.org Fri Sep 8 16:44:33 2023 From: joehw at openjdk.org (Joe Wang) Date: Fri, 8 Sep 2023 16:44:33 GMT Subject: RFR: 8306632: Add a JDK Property for specifying DTD support In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 18:41:48 GMT, Joe Wang wrote: > Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to specify how DTDs are handled. This property is uniformly supported across the JDK XML libraries. It complements, rather than replaces, the existing properties that are supportDTD for StAX and disallow-doctype-decl for DOM and SAX processors, which means the later will continue to work as they were and that if they are set, the new property will have no effect. Applications that use the existing properties continue to work as expected. > > This patch continues the path made previously with Xalan and XPath in which functions were moved into the jdk/xml classes. Similar changes are now made with the Xerces and XML classes, consolidating functions into the jdk/xml classes, reducing duplicate code for easier future maintenance. > > Tests: new tests are added to cover the various processors. > Existing tests pass. Only one was updated due to the change to the property impl. Thanks Stuart! Will integrate after re-run tests. Will look into the cleanups, along with the ones you suggested during the last review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15075#issuecomment-1711949388 From duke at openjdk.org Fri Sep 8 16:45:15 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 16:45:15 GMT Subject: RFR: 8315585: Optimization for decimal to string [v9] In-Reply-To: References: Message-ID: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request incrementally with one additional commit since the last revision: remove jla.newStringLatin1NoRepl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/ee3dd950..d5151ed3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=07-08 Stats: 53 lines in 5 files changed: 22 ins; 23 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From duke at openjdk.org Fri Sep 8 16:45:15 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 16:45:15 GMT Subject: RFR: 8315585: Optimization for decimal to string [v7] In-Reply-To: <1d_Syh-gpKsELKTluPvdGTnifqnWf382gvZuTt4LCIk=.947795e4-8ff5-4f72-a02d-3a1fd8b51a07@github.com> References: <7Qzi4prSgdVv-yZZ-SLubHrXd1taOsuVKAEwRUPSiH0=.f91d9d83-2893-4cf5-a8bc-32b9ab9f2642@github.com> <1d_Syh-gpKsELKTluPvdGTnifqnWf382gvZuTt4LCIk=.947795e4-8ff5-4f72-a02d-3a1fd8b51a07@github.com> Message-ID: On Fri, 8 Sep 2023 16:25:27 GMT, Roger Riggs wrote: >> I'll have a look at #14655 though I note that @RogerRiggs has already commented that this might not carry its own weight. These internal API bridges are a nuisance so we need to take care to make sure that any addition is actually necessary, not just convenient for the time being. > > I've recommended before to not add this convenience method, there's quite enough stuff in shared secrets and adds function that is too close to one already there. newStringLatin1NoRepl has been removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15555#discussion_r1320097174 From jlu at openjdk.org Fri Sep 8 17:14:06 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 8 Sep 2023 17:14:06 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v5] In-Reply-To: References: Message-ID: > Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern. > > `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified. > > The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor. > > The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html Justin Lu has updated the pull request incrementally with three additional commits since the last revision: - Make starting sentence consistent with other Format classes. Improve wording, a choiceFormat does NOT have to be created with only the arrays constructor. - Improve throws description for input that takes pattern - Make Format definition more consistent with other Format classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15392/files - new: https://git.openjdk.org/jdk/pull/15392/files/e3dafe6e..4103cf9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=03-04 Stats: 11 lines in 1 file changed: 4 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15392/head:pull/15392 PR: https://git.openjdk.org/jdk/pull/15392 From mchung at openjdk.org Fri Sep 8 17:41:05 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 8 Sep 2023 17:41:05 GMT Subject: RFR: 8285447: StackWalker minimal batch size should be optimized for getCallerClass Message-ID: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`. The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use). If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size. This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench. ------------- Commit messages: - 8285447: StackWalker minimal batch size should be optimized for getCallerClass Changes: https://git.openjdk.org/jdk/pull/15642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15642&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285447 Stats: 75 lines in 3 files changed: 60 ins; 10 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15642/head:pull/15642 PR: https://git.openjdk.org/jdk/pull/15642 From rriggs at openjdk.org Fri Sep 8 17:42:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Sep 2023 17:42:43 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v11] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Thu, 7 Sep 2023 17:58:09 GMT, Roger Riggs wrote: > A description of the DIGITS array layout and indexing is needed; it will help with the comprehension of the masking and shifts in the packDigits methods. The DIGITS table is missing a description of its indexing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320164002 From duke at openjdk.org Fri Sep 8 17:45:44 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 17:45:44 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v12] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Fri, 8 Sep 2023 00:00:16 GMT, ??? wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) >> >> >> >> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > reversed how & hi Is it good enough to integrate now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1712020725 From naoto at openjdk.org Fri Sep 8 17:48:47 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 8 Sep 2023 17:48:47 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v15] In-Reply-To: <75ndrilVt0qdL2-a8T3JZmsTeLVItTxCNN51UVEwnzA=.d9c2f952-98b1-46e0-9a1b-f241f6eb1963@github.com> References: <75ndrilVt0qdL2-a8T3JZmsTeLVItTxCNN51UVEwnzA=.d9c2f952-98b1-46e0-9a1b-f241f6eb1963@github.com> Message-ID: On Fri, 8 Sep 2023 14:43:59 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision: >> >> - Reflects review comments >> - Merge branch 'master' into JDK-8041488-ListPatterns-PR >> - Incorporating suggested changes >> - Update src/java.base/share/classes/java/text/ListFormat.java >> >> Co-authored-by: Roger Riggs >> - Update src/java.base/share/classes/java/text/ListFormat.java >> >> Co-authored-by: Roger Riggs >> - Update src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java >> >> Co-authored-by: Roger Riggs >> - Removing unnecessary commas >> - Added tests >> - Review comments >> - Merge branch 'master' into JDK-8041488-ListPatterns-PR >> - ... and 14 more: https://git.openjdk.org/jdk/compare/fa1dfefb...bce82a4f > > src/java.base/share/classes/java/text/ListFormat.java line 536: > >> 534: try { >> 535: init(); >> 536: } catch (IllegalArgumentException iae) { > > If the `patterns` array contains a null, perhaps due to corrupted stream contents, `init()` will throw NPE. > I don't recommend catching NPE here, but perhaps `init()` should check for nulls and throw IAE. Actually, null checks for the `patterns` array elements should be done also for the 1-arg factory method. Will add the check in `init()` and the corresponding test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1320169657 From naoto at openjdk.org Fri Sep 8 17:59:10 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 8 Sep 2023 17:59:10 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v16] In-Reply-To: References: Message-ID: > Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Check for null array elements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15130/files - new: https://git.openjdk.org/jdk/pull/15130/files/bce82a4f..19c0a201 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=14-15 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130 PR: https://git.openjdk.org/jdk/pull/15130 From duke at openjdk.org Fri Sep 8 18:10:33 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 8 Sep 2023 18:10:33 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v34] 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 incrementally with one additional commit since the last revision: Fix regression when intrinsics are disabled; enable insertion sort in intrinsic, change library name to libsimdsort ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14227/files - new: https://git.openjdk.org/jdk/pull/14227/files/0ec5f52d..c096ff62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=32-33 Stats: 590 lines in 20 files changed: 210 ins; 172 del; 208 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 Fri Sep 8 18:17:12 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 18:17:12 GMT Subject: RFR: 8315585: Optimization for decimal to string [v10] In-Reply-To: References: Message-ID: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request incrementally with one additional commit since the last revision: bug fix & add testcases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/d5151ed3..c4425ddd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=08-09 Stats: 5 lines in 3 files changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From bchristi at openjdk.org Fri Sep 8 18:47:41 2023 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 8 Sep 2023 18:47:41 GMT Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2] In-Reply-To: References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com> <_b4wRbfmijSU1QL-bMrBvy5wQoaQp8fFO96SdOuE438=.923f52e6-b930-47c4-8e08-e7b299722657@github.com> Message-ID: On Fri, 8 Sep 2023 08:03:51 GMT, Alan Bateman wrote: > > We could do this mid-term in some follow up action. > > It shouldn't be hard to try it. If it works out then it would mean this old crufty code goes away and the JDK is in a better place. If it doesn't work out then the a plan B would be to add to have lockFile0 throw with a useful exception. I would also like to see what a FileChannel implementation looks like. Am I right that this would allow the `prefs` native library to be removed entirely? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1712087144 From duke at openjdk.org Fri Sep 8 18:53:53 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 8 Sep 2023 18:53:53 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v34] In-Reply-To: References: Message-ID: <14oyMTTPLnPXFJRddbU8WOuWSIr4WDp0QtvIYbH6jD8=.1fa0eb21-2d02-43d4-932b-c0aa331aeb0a@github.com> On Fri, 8 Sep 2023 18:10:33 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: > > Fix regression when intrinsics are disabled; enable insertion sort in intrinsic, change library name to libsimdsort > > > > Hi @vamsi-parasa , > > Please find below the perf data collected over ?Linux? with following JMH options. Idea here is to measure the impact of Java side code re-structuring over non-x86 targets and windows machines which do not intrinsify newly created primitives. > > java -jar target/benchmarks.jar -p builder=RANDOM -f 1 -wi 1 -i 10 -w 30 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySort,_arrayPartition" ArraysSort.Long.testSort > > Baseline numbers are with stock JDK. > > ![image](https://user-images.githubusercontent.com/59989778/264077119-d3bf2591-38bb-4924-b77d-6889c5dbc3c0.png) > > It will also be good to mention in PR description as to why are not accelerating sorting for short/char arrays when x86-simd-sort does have avx512 optimized versions for 16-bit arrays sorting. > > Best Regards, Jatin Hello Jatin, In the table below, please see the performance data (on Linux x86 machine) when the intrinsics are disabled w.r.t to the stock JDK as baseline. The regression is fixed in the latest commit pushed. This data was collected using the same way as yours: `java -jar target/benchmarks.jar -p builder=RANDOM -f 1 -wi 1 -i 10 -w 30 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySortI,_arraySortMI,_arrayPartitionSP,_arrayPartitionDP" ArraysSort.Long.testSort` Please note the new names of the intrinsics. Benchmark | (builder) | (size) | Baseline (Stock JDK) us/op | RSD (baseline) | AVX512 sort (intrinsics disabled) us/op | RSD (AVX512 sort) | Speedup -- | -- | -- | -- | -- | -- | -- | -- ArraysSort.Long.testSort | RANDOM | 800 | 6.4 | 0.1% | 6.3 | 0.43% | 1.02 ArraysSort.Long.testSort | RANDOM | 7000 | 210.2 | 0.5% | 205.5 | 0.24% | 1.02 ArraysSort.Long.testSort | RANDOM | 50000 | 2087.2 | 0.1% | 2057.5 | 0.18% | 1.01 ArraysSort.Long.testSort | RANDOM | 300000 | 14076.0 | 0.3% | 14245.2 | 0.13% | 0.99 ArraysSort.Long.testSort | RANDOM | 2000000 | 111576.6 | 0.4% | 110024.9 | 0.04% | 1.01 Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1712092760 From duke at openjdk.org Fri Sep 8 18:57:41 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 18:57:41 GMT Subject: RFR: 8315585: Optimization for decimal to string [v10] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 18:17:12 GMT, ??? wrote: >> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. >> >> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. >> >> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. >> >> The performance data is as follows: >> >> ## 1. benchmark script >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.math.BigDecimals.*ToPlainString" >> make test TEST="micro:java.math.BigDecimals.*ToEngineering" >> >> >> ## 2. benchmark environment >> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) >> * cpu intel xeon sapphire rapids (x64) >> >> ## 3. benchmark result >> >> -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) >> -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op >> -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op >> -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) >> +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) >> +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) >> +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) >> >> -Benchmark Mode Cnt Score Error Units (baseline) >> -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op >> -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op >> -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op >> -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op >> >> +Benchmark Mode Cnt Score Error Units (optimize) >> +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) >> +BigDecimals.testLargeToEngineeringStr... > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > bug fix & add testcases The new performance data is as follows: ## 1. benchmark script sh make/devkit/createJMHBundle.sh bash configure --with-jmh=build/jmh/jars make test TEST="micro:java.math.BigDecimals.*ToPlainString" make test TEST="micro:java.math.BigDecimals.*ToEngineering" ## 2. benchmark environment * baseline https://github.com/wenshao/jdk/tree/baseline_test * optimize version : 09 [Full](https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=09) - [Incremental](https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=08-09) ([c4425ddd](https://git.openjdk.org/jdk/pull/15555/files/c4425dddef7dbb9e6ee0851fde8561869bf0ddd5)) ## 3. benchmark result ## 3.1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) * cpu : intel xeon sapphire rapids (x64) * os : Alibaba Cloud Linux 3.2104 LTS 64 -Benchmark Mode Cnt Score Error Units (baseline) -BigDecimals.testHugeToPlainString avgt 15 188.687 ? 0.210 ns/op -BigDecimals.testLargeToPlainString avgt 15 36.547 ? 0.083 ns/op -BigDecimals.testSmallToPlainString avgt 15 34.270 ? 0.075 ns/op -BigDecimals.testToPlainString avgt 15 1661.588 ? 25.568 ns/op +Benchmark Mode Cnt Score Error Units (optimized) +BigDecimals.testHugeToPlainString avgt 15 117.868 ? 0.390 ns/op (+60.08%) +BigDecimals.testLargeToPlainString avgt 15 15.903 ? 0.069 ns/op (+129.81%) +BigDecimals.testSmallToPlainString avgt 15 13.502 ? 0.051 ns/op (+153.81%) +BigDecimals.testToPlainString avgt 15 1556.691 ? 19.407 ns/op (+6.73%) -Benchmark Mode Cnt Score Error Units (baseline) -BigDecimals.testHugeToEngineeringString avgt 15 207.858 ? 4.166 ns/op -BigDecimals.testLargeToEngineeringString avgt 15 35.723 ? 2.772 ns/op -BigDecimals.testSmallToEngineeringString avgt 15 15.083 ? 0.052 ns/op -BigDecimals.testToEngineeringString avgt 15 1715.916 ? 37.066 ns/op +Benchmark Mode Cnt Score Error Units (optimized) +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+46.26%) +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.57%) +BigDecimals.testSmallToEngineeringString avgt 15 10.579 ? 0.066 ns/op (+42.57%) +BigDecimals.testToEngineeringString avgt 15 1646.783 ? 3.060 ns/op (+4.19%) ## 3.2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) * cpu : amd epc genoa (x64) * os : Alibaba Cloud Linux 3.2104 LTS 64 -Benchmark Mode Cnt Score Error Units (baseline) -BigDecimals.testHugeToEngineeringString avgt 15 300.712 ? 8.526 ns/op -BigDecimals.testLargeToEngineeringString avgt 15 42.108 ? 0.149 ns/op -BigDecimals.testSmallToEngineeringString avgt 15 24.333 ? 0.076 ns/op -BigDecimals.testToEngineeringString avgt 15 2300.080 ? 12.640 ns/op +Benchmark Mode Cnt Score Error Units (optimized) +BigDecimals.testHugeToEngineeringString avgt 15 161.471 ? 1.303 ns/op (+86.23%) +BigDecimals.testLargeToEngineeringString avgt 15 24.847 ? 0.111 ns/op (+69.46%) +BigDecimals.testSmallToEngineeringString avgt 15 21.529 ? 0.088 ns/op (+13.02%) +BigDecimals.testToEngineeringString avgt 15 2016.281 ? 21.728 ns/op (+14.07%) -Benchmark Mode Cnt Score Error Units (baseline) -BigDecimals.testHugeToPlainString avgt 15 277.892 ? 1.485 ns/op -BigDecimals.testLargeToPlainString avgt 15 42.669 ? 0.075 ns/op -BigDecimals.testSmallToPlainString avgt 15 38.928 ? 0.402 ns/op -BigDecimals.testToPlainString avgt 15 2245.593 ? 20.488 ns/op +Benchmark Mode Cnt Score Error Units (optimized) +BigDecimals.testHugeToPlainString avgt 15 154.470 ? 7.259 ns/op (+79.90%) +BigDecimals.testLargeToPlainString avgt 15 29.892 ? 0.290 ns/op (+42.74%) +BigDecimals.testSmallToPlainString avgt 15 25.605 ? 0.109 ns/op (+52.03%) +BigDecimals.testToPlainString avgt 15 2027.892 ? 12.792 ns/op (+10.73%) ## MaxBookPro M1 Pro -Benchmark Mode Cnt Score Error Units (baseline) -BigDecimals.testHugeToEngineeringString avgt 15 250.340 ? 4.911 ns/op -BigDecimals.testLargeToEngineeringString avgt 15 83.954 ? 7.603 ns/op -BigDecimals.testSmallToEngineeringString avgt 15 17.321 ? 0.083 ns/op -BigDecimals.testToEngineeringString avgt 15 1874.298 ? 71.820 ns/op +Benchmark Mode Cnt Score Error Units (optimized) +BigDecimals.testHugeToEngineeringString avgt 15 104.412 ? 17.752 ns/op (+139.76%) +BigDecimals.testLargeToEngineeringString avgt 15 14.617 ? 0.380 ns/op (+474.35%) +BigDecimals.testSmallToEngineeringString avgt 15 11.960 ? 0.021 ns/op (+44.82%) +BigDecimals.testToEngineeringString avgt 15 1622.669 ? 81.835 ns/op (+15.50%) -Benchmark Mode Cnt Score Error Units (baseline) -BigDecimals.testHugeToPlainString avgt 15 188.559 ? 9.283 ns/op -BigDecimals.testLargeToPlainString avgt 15 22.894 ? 0.102 ns/op -BigDecimals.testSmallToPlainString avgt 15 24.029 ? 0.164 ns/op -BigDecimals.testToPlainString avgt 15 1858.483 ? 56.941 ns/op +Benchmark Mode Cnt Score Error Units (optimized) +BigDecimals.testHugeToPlainString avgt 15 87.264 ? 0.677 ns/op (+116.07%) +BigDecimals.testLargeToPlainString avgt 15 16.665 ? 0.045 ns/op (+37.37%) +BigDecimals.testSmallToPlainString avgt 15 13.467 ? 0.091 ns/op (+78.42%) +BigDecimals.testToPlainString avgt 15 1593.317 ? 84.553 ns/op (+16.64%) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1712096597 From duke at openjdk.org Fri Sep 8 18:58:39 2023 From: duke at openjdk.org (altrisi) Date: Fri, 8 Sep 2023 18:58:39 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`: >> >> * Code reuse >> * A field declared `final` >> * Add missing `@Override` annotations > > 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 With the recent changes this ends up just moving the iterator classes around (from anonymous to inner) and making a field final. I don't understand how fully splitting them (vs the previous `AbstractIterator` revision) helps against polymorphism, given they both would store the same `Iterator` types in the field (whatever the result of `entrySet` is), and the `next` method is two different implementations anyway, that I'd assume would be treated differently. Though I don't know enough about the JIT (or benchmarked this) to know if it does make a difference. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15615#issuecomment-1712097625 From alanb at openjdk.org Fri Sep 8 19:01:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Sep 2023 19:01:00 GMT Subject: RFR: 8315938: Deprecate for removal Unsafe methods that have standard APIs for many releases Message-ID: There are several methods defined by sun.misc.Unsafe that have standard API equivalents for many years and releases. The change proposed here is to deprecate, for removal, the park, unpark, getLoadAverage, loadFence, storeFence, and fullFence methods. Code using these methods should move to LockSupport.park/unpark (Java 5), OperatingSystemMXBean.getSystemLoadAverage (Java 6), and VarHandles xxxFence methods (Java 9). The following is a summary of a search of 175973022 classes in 484751 artifacts to get a sense of the usage of these methods. - 1290 usages of Unsafe.park. 1195 are libraries that have re-packaged some version of ForkJoinPool, maybe from the jsr166 repo, maybe an older JDK release. In the remaining, only Ehcache stands out with 29 matches. It seems to be one usage but the library seems to copied/shaded into other artifacts. - 1322 usages of Unsafe.unpark. 1243 are re-packaged ForkJoinPool. 29 occurrences are Encache, again one usage but the library seems to copied/shaded into other artifacts. - 22 usages of Unsafe.getLoadAverage. Most of these are one usage in many published versions of Apache HBase. - 339 usages of Unsafe.loadFence, 1057 usages of Unsafe.storeFence, 517 usages of Unsafe.fullFence. A handful of these are libraries with copies of j.u.concurrent, the rest seem to be high performance libraries that support older JDK releases or just haven't been updated to use VarHandles yet. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/15641/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15641&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315938 Stats: 22 lines in 1 file changed: 20 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15641.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15641/head:pull/15641 PR: https://git.openjdk.org/jdk/pull/15641 From rriggs at openjdk.org Fri Sep 8 19:01:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Sep 2023 19:01:43 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v12] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Fri, 8 Sep 2023 00:00:16 GMT, ??? wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) >> >> >> >> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > reversed how & hi This request got buried in a "resolved" comment: > A description of the DIGITS array layout and indexing is needed; it will help with the comprehension of the masking and shifts in the packDigits methods. The DIGITS table is missing a description of its indexing. ------------- Changes requested by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14745#pullrequestreview-1618092342 From duke at openjdk.org Fri Sep 8 19:11:05 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 19:11:05 GMT Subject: RFR: 8315585: Optimization for decimal to string [v11] In-Reply-To: References: Message-ID: > BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal. > > The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance. > > Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering. > > The performance data is as follows: > > ## 1. benchmark script > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.math.BigDecimals.*ToPlainString" > make test TEST="micro:java.math.BigDecimals.*ToEngineering" > > > ## 2. benchmark environment > * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i) > * cpu intel xeon sapphire rapids (x64) > > ## 3. benchmark result > > -BigDecimals.testHugeToPlainString avgt 15 188.691 ? 0.822 ns/op (baseline) > -BigDecimals.testLargeToPlainString avgt 15 36.656 ? 0.065 ns/op > -BigDecimals.testSmallToPlainString avgt 15 34.342 ? 0.068 ns/op > -BigDecimals.testToPlainString avgt 15 1719.494 ? 24.886 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToPlainString avgt 15 133.972 ? 0.328 ns/op (+40.84%) > +BigDecimals.testLargeToPlainString avgt 15 14.957 ? 0.047 ns/op (145.07%) > +BigDecimals.testSmallToPlainString avgt 15 12.045 ? 0.036 ns/op (+185.11) > +BigDecimals.testToPlainString avgt 15 1643.500 ? 3.217 ns/op (+4.62%) > > -Benchmark Mode Cnt Score Error Units (baseline) > -BigDecimals.testHugeToEngineeringString avgt 15 207.621 ? 5.018 ns/op > -BigDecimals.testLargeToEngineeringString avgt 15 35.658 ? 3.144 ns/op > -BigDecimals.testSmallToEngineeringString avgt 15 15.142 ? 0.053 ns/op > -BigDecimals.testToEngineeringString avgt 15 1813.959 ? 12.842 ns/op > > +Benchmark Mode Cnt Score Error Units (optimize) > +BigDecimals.testHugeToEngineeringString avgt 15 142.110 ? 0.987 ns/op (+45.09%) > +BigDecimals.testLargeToEngineeringString avgt 15 12.509 ? 0.056 ns/op (+185.05%) > +BigDecimals.testSmallToEngineer... ??? has updated the pull request incrementally with one additional commit since the last revision: fix scale 19 error & add testcases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15555/files - new: https://git.openjdk.org/jdk/pull/15555/files/c4425ddd..562869d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15555&range=09-10 Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555 PR: https://git.openjdk.org/jdk/pull/15555 From duke at openjdk.org Fri Sep 8 19:16:52 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 8 Sep 2023 19:16:52 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30] In-Reply-To: References: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com> Message-ID: <31NkipkbxArsTh5jQduF2Bl7xo6UQ9R_zYt6k_0RpG0=.68959245-74c2-4135-a012-7906946917a0@github.com> On Fri, 1 Sep 2023 10:57:57 GMT, iaroslavski wrote: >>> @AlanBateman If it helps, the changes made by @vamsi-parasa to DualPivotQuickSort.java don't change the logic as written in Java. They only carve out the functionality into separate Java methods retaining the meaning exactly as before. These Java methods are then optimized through a stub. >> >> Hi Alan, >> >> As Sandhya (@sviswa7) mentioned, this PR does not make any logic changes to the DualPivotQuickSort.java. >> >> The code was refactored to separate out the partitioning logic (dual pivot and single pivot) into separate methods. These methods are being intrinsified using AVX512 to do vectorized partitioning preserving the logic of Java side. Similarly, the methods to sort small arrays (insertionSort/mixedInsertionSort) are being intrinsified as well to use AVX512 sort while preserving the logic on Java side. >> >> Could you please go through the changes and provide your comments and suggestions? >> >> Thanks, >> Vamsi > > Hi Vamsi (@vamsi-parasa)! > > Please see my few questions/suggestions related to method arraySort() and other code. > > **1.** If size < MIN_FAST_SMALL_ARRAY_SORT_SIZE (=16), you don't go into intrinsic arraySort(), method > mixedInsertionSort is invoked instead. > > `if (size < MAX_MIXED_INSERTION_SORT_SIZE + bits && (bits & 1) > 0) {` > ` int last = high - 3 * ((size >> 5) << 3);` > ` if (size < MIN_FAST_SMALL_ARRAY_SORT_SIZE) mixedInsertionSort(a, low, last , high);` > ` else arraySort(int.class, a, baseOffset, low, high, last);` > ` return;` > `}` > > Is Java mixedInsertionSort actually faster than intrinsic arraySort() on small (< 16) arrays? > What if you try to invoke arraySort() on all small arrays and don't use constant MIN_FAST_SMALL_ARRAY_SORT_SIZE at all? > Like this: > > `if (size < MAX_MIXED_INSERTION_SORT_SIZE + bits && (bits & 1) > 0) {` > ` int last = high - 3 * ((size >> 5) << 3);` > ` arraySort(int.class, a, baseOffset, low, high, last);` > ` return;` > `}` > > Could you please check and benchmark it? > > **2.** On the next step you apply the same approach when you invoke insertionSort() on the small leftmost part. > > `if (size < MAX_INSERTION_SORT_SIZE) {` > ` if (size < MIN_FAST_SMALL_ARRAY_SORT_SIZE) insertionSort(a, low, high);` > ` else arraySort(int.class, a, baseOffset, low, high, -1);` > ` return;` > `}` > > But this invocation happens only once, on the leftmost part only. I think we can invoke Java code and > don't go to intrinsic arraySort(). I guess we will not have profit with intrinsic method here. See: > > `if (size < MAX_INSERTION_SORT_SIZE) {` > ` insertionSort(a, low, high);` > ` return;` > `}` > > Could you please try this case without intrinsic and benchmark it? > > **3.** You introduce constant int baseOffset = Unsafe.ARRAY_INT_BASE_OFFSET inside the loop. > What if we pass the constant directly? For example: > > `arraySort(int.class, a, Unsafe.ARRAY_INT_BASE_OFFSET, low, high, last);` > > **3.A** The first parameter of arraySort() is elemType (int.class, long,class etc.) > The second parameter base offset depends on this elem type. For example, > if elemType is int.class, base offset will be Unsafe.ARRAY_INT_BASE_OFFSET. > Can we eliminate base offset here and set up value inside intrinsic? > > **4.** You define 'int[] pivotIndices;' at the beginning of the loop, but the indices will be used > later (or not used at all). My proposal to declare pivotIndices in if-then-else, see: > > `int[] pivotIndices = new int[] {e1, e5};` > > **5.** Method arrayPartition has argument isDualPi... Hello Vladimir (@iaroslavski) Please have a look at the new commit that was recently pushed. It incorporates the various suggestions you've given. For small arrays (<16 for 32bit types and <20 for 64 bit types), it was observed that insertionSort is faster than the AVX512 bitonic sort. In order to address this, the insertionSort has been moved into the native instrinsic and is now actually slightly faster than the Java version as seen int the table below. On the Java side, it looks cleaner as there are no threshold checks to switch between the intrinsic and Java insertion sort. Benchmark | (builder) | Size | Insertion Sort (Java) | AVX512 bitonic sort | Speedup (before) | AVX512 bitonic + Insertion Sort (C++) | Speedup (now) -- | -- | -- | -- | -- | -- | -- | -- ArraysSort.Long.testSort | RANDOM | 5 | 0.021 | 0.042 | 0.50 | 0.019 | 1.11 ArraysSort.Long.testSort | RANDOM | 10 | 0.037 | 0.061 | 0.61 | 0.031 | 1.19 ArraysSort.Long.testSort | RANDOM | 15 | 0.055 | 0.055 | 1.00 | 0.054 | 1.02 ArraysSort.Long.testSort | RANDOM | 20 | 0.077 | 0.08 | 0.96 | 0.069 | 1.12 ArraysSort.Long.testSort | RANDOM | 25 | 0.102 | 0.079 | 1.29 | 0.079 | 1.29 ArraysSort.Long.testSort | RANDOM | 50 | 0.253 | 0.233 | 1.09 | 0.238 | 1.06 ArraysSort.Long.testSort | RANDOM | 75 | 0.381 | 0.291 | 1.31 | 0.282 | 1.35 Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1712116207 From forax at openjdk.org Fri Sep 8 19:20:38 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 8 Sep 2023 19:20:38 GMT Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes [v3] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 18:55:29 GMT, altrisi wrote: >> 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 > > With the recent changes this ends up just moving the iterator classes around (from anonymous to inner) and making a field final. I don't understand how fully splitting them (vs the previous `AbstractIterator` revision) helps against polymorphism, given they both would store the same `Iterator` types in the field (whatever the result of `entrySet` is), and the `next` method is two different implementations anyway, that I'd assume would be treated differently. Though I don't know enough about the JIT (or benchmarked this) to know if it does make a difference. @altrisi, the profile stored by the VM is attached to a specific bytecode, if you share that bytecode, you share the profile. see https://wiki.openjdk.org/display/HotSpot/MethodData ------------- PR Comment: https://git.openjdk.org/jdk/pull/15615#issuecomment-1712119725 From mchung at openjdk.org Fri Sep 8 19:24:38 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 8 Sep 2023 19:24:38 GMT Subject: RFR: 8315938: Deprecate for removal Unsafe methods that have standard APIs for many releases In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 15:54:05 GMT, Alan Bateman wrote: > There are several methods defined by sun.misc.Unsafe that have standard API equivalents for many years and releases. The change proposed here is to deprecate, for removal, the park, unpark, getLoadAverage, loadFence, storeFence, and fullFence methods. Code using these methods should move to LockSupport.park/unpark (Java 5), OperatingSystemMXBean.getSystemLoadAverage (Java 6), and VarHandles xxxFence methods (Java 9). > > The following is a summary of a search of 175973022 classes in 484751 artifacts to get a sense of the usage of these methods. > > - 1290 usages of Unsafe.park. 1195 are libraries that have re-packaged some version of ForkJoinPool, maybe from the jsr166 repo, maybe an older JDK release. In the remaining, only Ehcache stands out with 29 matches. It seems to be one usage but the library seems to copied/shaded into other artifacts. > > - 1322 usages of Unsafe.unpark. 1243 are re-packaged ForkJoinPool. 29 occurrences are Encache, again one usage but the library seems to copied/shaded into other artifacts. > > - 22 usages of Unsafe.getLoadAverage. Most of these are one usage in many published versions of Apache HBase. > > - 339 usages of Unsafe.loadFence, 1057 usages of Unsafe.storeFence, 517 usages of Unsafe.fullFence. A handful of these are libraries with copies of j.u.concurrent, the rest seem to be high performance libraries that support older JDK releases or just haven't been updated to use VarHandles yet. A good set of Unsafe APIs for terminal deprecation and the API replacements exist for some time. ------------- Marked as reviewed by mchung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15641#pullrequestreview-1618121782 From duke at openjdk.org Fri Sep 8 19:36:55 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 8 Sep 2023 19:36:55 GMT Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v34] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 18:10:33 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: > > Fix regression when intrinsics are disabled; enable insertion sort in intrinsic, change library name to libsimdsort Hello Paul, Could you please take a look at the Java side changes in the new commit that was pushed? It fixes the regression that was observed when the intrinsics were disabled. It turns out that the switch is not the problem. Separating the intrinsics for` insertionSort` and `mixedInsertionSort` into separate methods (while retaining the switch based dispatch) + returning pivotIndices as an integer array, is fixing the regression when intrinsics are disabled. (For `MemorySegment`, a long array of indices could be returned.) > That's surprising, i wonder if that is related to the use of switch and somehow C2 cannot elide the allocation via escape analysis? One solution to avoid allocation is to pack the return of the two indices in a long value. That may also simplify the C2 intrinsic implementation. However, that restricts indices to int values. To support `MemorySegment` we need to support long value indices. > When passing the pivotIndices array as a parameter, regression was observed even in the absence of the intrinsic (i.e. switch). To test this, I took the stock JDK implementation of the `DualPivotQuicksort.java` and just only refactored the partitioning logic into separate methods. There were no intrinsics at all. Even in this case, there was a regression of up to 12%. Passing the pivots as seperate parameters and returning the updated pivot indices as a new array fixed the regression. Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1712135477 From psandoz at openjdk.org Fri Sep 8 19:46:37 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 8 Sep 2023 19:46:37 GMT Subject: RFR: 8315938: Deprecate for removal Unsafe methods that have standard APIs for many releases In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 15:54:05 GMT, Alan Bateman wrote: > There are several methods defined by sun.misc.Unsafe that have standard API equivalents for many years and releases. The change proposed here is to deprecate, for removal, the park, unpark, getLoadAverage, loadFence, storeFence, and fullFence methods. Code using these methods should move to LockSupport.park/unpark (Java 5), OperatingSystemMXBean.getSystemLoadAverage (Java 6), and VarHandles xxxFence methods (Java 9). > > The following is a summary of a search of 175973022 classes in 484751 artifacts to get a sense of the usage of these methods. > > - 1290 usages of Unsafe.park. 1195 are libraries that have re-packaged some version of ForkJoinPool, maybe from the jsr166 repo, maybe an older JDK release. In the remaining, only Ehcache stands out with 29 matches. It seems to be one usage but the library seems to copied/shaded into other artifacts. > > - 1322 usages of Unsafe.unpark. 1243 are re-packaged ForkJoinPool. 29 occurrences are Encache, again one usage but the library seems to copied/shaded into other artifacts. > > - 22 usages of Unsafe.getLoadAverage. Most of these are one usage in many published versions of Apache HBase. > > - 339 usages of Unsafe.loadFence, 1057 usages of Unsafe.storeFence, 517 usages of Unsafe.fullFence. A handful of these are libraries with copies of j.u.concurrent, the rest seem to be high performance libraries that support older JDK releases or just haven't been updated to use VarHandles yet. Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15641#pullrequestreview-1618162112 From duke at openjdk.org Fri Sep 8 20:01:20 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 20:01:20 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v13] In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: <8kNgEhkrSffUi8eDckLlME5buq-kUnOssnzD-f_ZeKI=.839ccfe4-7134-4114-98fd-bd259aff4b0c@github.com> > [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.util.UUIDBench.toString" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) > > > > ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) > * cpu : aliyun yitian 710 (aarch64) > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) > > > ## 4. MacBookPro M1 Pro > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) > > > ## 5. Orange Pi 5 Plus > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us > > +Benchmark (size) Mode Cnt Score Error Units (PR) > +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) ??? has updated the pull request incrementally with one additional commit since the last revision: add DIGITS description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14745/files - new: https://git.openjdk.org/jdk/pull/14745/files/747e8135..384354d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=11-12 Stats: 27 lines in 1 file changed: 27 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14745/head:pull/14745 PR: https://git.openjdk.org/jdk/pull/14745 From duke at openjdk.org Fri Sep 8 20:01:22 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 20:01:22 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v12] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Fri, 8 Sep 2023 18:59:09 GMT, Roger Riggs wrote: > This request got buried in a "resolved" comment: > > > A description of the DIGITS array layout and indexing is needed; it will help with the comprehension of the masking and shifts in the packDigits methods. > > The DIGITS table is missing a description of its indexing. Sorry, I have already added the description of DIGITS ------------- PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1712157546 From duke at openjdk.org Fri Sep 8 20:06:39 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 20:06:39 GMT Subject: RFR: 8315789: Minor HexFormat performance improvements In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 08:47:04 GMT, Raffaello Giulietti wrote: > I'm not sure that micro-benchmarks are very indicative on whether a lookup table performs better than short and straightforward code. > The reason is that, once in the CPU caches, a lookup table in micro-benchmarks stays there, whereas in more realistic situations, where access is more spread out in time, it is often evicted to make room for other, more lively data. > A micro-benchmark using a lookup table shows good results because of a high rate of cache hits, whereas in other real-world workloads a lookup table might result in many cache misses on access. In the HexFormat scenario, if the length of the input byte[] is larger, the performance of using the lookup table will be better. If the length of byte[] is greater than 1 in most scenarios, using lookup table will have better performance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15591#issuecomment-1712164869 From rriggs at openjdk.org Fri Sep 8 20:21:42 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Sep 2023 20:21:42 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v13] In-Reply-To: <8kNgEhkrSffUi8eDckLlME5buq-kUnOssnzD-f_ZeKI=.839ccfe4-7134-4114-98fd-bd259aff4b0c@github.com> References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> <8kNgEhkrSffUi8eDckLlME5buq-kUnOssnzD-f_ZeKI=.839ccfe4-7134-4114-98fd-bd259aff4b0c@github.com> Message-ID: On Fri, 8 Sep 2023 20:01:20 GMT, ??? wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) >> >> >> >> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > add DIGITS description Thank you improvements. src/java.base/share/classes/java/util/HexDigits.java line 81: > 79: for (int j = 0; j < 16; j++) { > 80: short hi = (short) ((j < 10 ? j + '0' : j - 10 + 'a') << 8); > 81: digits[(i << 4) + j] = (short) (lo | hi); The part that is counter-intuitive is that the bits that are shifted left appear to the right of the bits that are not shifted. (the actual bits are correct, either way, but it reads oddly). In a short, the resulting bits would be `hhll`. Suggestion: digits[(i << 4) + j] = (short) (hi | lo); Similarly, the returns of the other `packDigits` methods do not read MSB to LSB. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14745#pullrequestreview-1618197721 PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320299608 From joehw at openjdk.org Fri Sep 8 20:24:43 2023 From: joehw at openjdk.org (Joe Wang) Date: Fri, 8 Sep 2023 20:24:43 GMT Subject: RFR: 8306632: Add a JDK Property for specifying DTD support [v2] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 16:44:31 GMT, Joe Wang wrote: >> Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to specify how DTDs are handled. This property is uniformly supported across the JDK XML libraries. It complements, rather than replaces, the existing properties that are supportDTD for StAX and disallow-doctype-decl for DOM and SAX processors, which means the later will continue to work as they were and that if they are set, the new property will have no effect. Applications that use the existing properties continue to work as expected. >> >> This patch continues the path made previously with Xalan and XPath in which functions were moved into the jdk/xml classes. Similar changes are now made with the Xerces and XML classes, consolidating functions into the jdk/xml classes, reducing duplicate code for easier future maintenance. >> >> Tests: new tests are added to cover the various processors. >> Existing tests pass. Only one was updated due to the change to the property impl. > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8306632 > Sync up to re-run tests. > - fix Whitespace errors > - 8306632: Add a JDK Property for specifying DTD support Tier1 and Tier3 passed! Tier2 with one known failure (intermittent). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15075#issuecomment-1712181235 From naoto at openjdk.org Fri Sep 8 20:25:45 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 8 Sep 2023 20:25:45 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v5] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 17:14:06 GMT, Justin Lu wrote: >> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern. >> >> `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified. >> >> The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor. >> >> The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html > > Justin Lu has updated the pull request incrementally with three additional commits since the last revision: > > - Make starting sentence consistent with other Format classes. Improve wording, a choiceFormat does NOT have to be created with only the arrays constructor. > - Improve throws description for input that takes pattern > - Make Format definition more consistent with other Format classes LGTM, with a minor nit. src/java.base/share/classes/java/text/ChoiceFormat.java line 155: > 153: * "#" / "<" / "≤" > 154: * Format: > 155: * Any unicode characters except the Relation symbols Nit: since characters in Java are of Unicode code points, no need to mention `unicode` here. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15392#pullrequestreview-1618209049 PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1320305820 From joehw at openjdk.org Fri Sep 8 20:27:50 2023 From: joehw at openjdk.org (Joe Wang) Date: Fri, 8 Sep 2023 20:27:50 GMT Subject: Integrated: 8306632: Add a JDK Property for specifying DTD support In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 18:41:48 GMT, Joe Wang wrote: > Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to specify how DTDs are handled. This property is uniformly supported across the JDK XML libraries. It complements, rather than replaces, the existing properties that are supportDTD for StAX and disallow-doctype-decl for DOM and SAX processors, which means the later will continue to work as they were and that if they are set, the new property will have no effect. Applications that use the existing properties continue to work as expected. > > This patch continues the path made previously with Xalan and XPath in which functions were moved into the jdk/xml classes. Similar changes are now made with the Xerces and XML classes, consolidating functions into the jdk/xml classes, reducing duplicate code for easier future maintenance. > > Tests: new tests are added to cover the various processors. > Existing tests pass. Only one was updated due to the change to the property impl. This pull request has now been integrated. Changeset: dccf6704 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/dccf6704925715e62dcbf84ac11930298913e173 Stats: 3337 lines in 71 files changed: 2019 ins; 1135 del; 183 mod 8306632: Add a JDK Property for specifying DTD support Reviewed-by: lancea, smarks ------------- PR: https://git.openjdk.org/jdk/pull/15075 From duke at openjdk.org Fri Sep 8 20:36:31 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 20:36:31 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14] In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: > [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. > > # Benchmark Result > > > sh make/devkit/createJMHBundle.sh > bash configure --with-jmh=build/jmh/jars > make test TEST="micro:java.util.UUIDBench.toString" > > > ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) > * cpu : intel xeon sapphire rapids (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) > > > ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) > * cpu : amd epc genoa (x64) > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) > > > > ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) > * cpu : aliyun yitian 710 (aarch64) > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) > > > ## 4. MacBookPro M1 Pro > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us > > +Benchmark (size) Mode Cnt Score Error Units > +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) > > > ## 5. Orange Pi 5 Plus > > ``` diff > -Benchmark (size) Mode Cnt Score Error Units (baseline) > -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us > > +Benchmark (size) Mode Cnt Score Error Units (PR) > +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) ??? has updated the pull request incrementally with one additional commit since the last revision: lo | hi => hi | lo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14745/files - new: https://git.openjdk.org/jdk/pull/14745/files/384354d9..46b4b057 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14745/head:pull/14745 PR: https://git.openjdk.org/jdk/pull/14745 From duke at openjdk.org Fri Sep 8 20:36:34 2023 From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=) Date: Fri, 8 Sep 2023 20:36:34 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v13] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> <8kNgEhkrSffUi8eDckLlME5buq-kUnOssnzD-f_ZeKI=.839ccfe4-7134-4114-98fd-bd259aff4b0c@github.com> Message-ID: On Fri, 8 Sep 2023 20:13:01 GMT, Roger Riggs wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> add DIGITS description > > src/java.base/share/classes/java/util/HexDigits.java line 81: > >> 79: for (int j = 0; j < 16; j++) { >> 80: short hi = (short) ((j < 10 ? j + '0' : j - 10 + 'a') << 8); >> 81: digits[(i << 4) + j] = (short) (lo | hi); > > The part that is counter-intuitive is that the bits that are shifted left appear to the right of the bits that are not shifted. (the actual bits are correct, either way, but it reads oddly). In a short, the resulting bits would be `hhll`. > Suggestion: > > digits[(i << 4) + j] = (short) (hi | lo); > > Similarly, the returns of the other `packDigits` methods do not read MSB to LSB. You are right, I have changed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320310958 From duke at openjdk.org Fri Sep 8 21:09:42 2023 From: duke at openjdk.org (ExE Boss) Date: Fri, 8 Sep 2023 21:09:42 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Fri, 8 Sep 2023 20:36:31 GMT, ??? wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) >> >> >> >> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > lo | hi => hi | lo src/java.base/share/classes/java/util/HexDigits.java line 66: > 64: */ > 65: @Stable > 66: private static final short[] DIGITS; Maybe?it?should be?`char[]`?instead since?it?s?encoded using?unsigned 16?bit?integers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320341536 From jlu at openjdk.org Fri Sep 8 21:11:11 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 8 Sep 2023 21:11:11 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v6] In-Reply-To: References: Message-ID: > Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern. > > `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified. > > The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor. > > The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Drop Unicode from definition, implied ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15392/files - new: https://git.openjdk.org/jdk/pull/15392/files/4103cf9b..216e5ac7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15392/head:pull/15392 PR: https://git.openjdk.org/jdk/pull/15392 From jlu at openjdk.org Fri Sep 8 21:11:11 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 8 Sep 2023 21:11:11 GMT Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well documented. [v5] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 20:21:56 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with three additional commits since the last revision: >> >> - Make starting sentence consistent with other Format classes. Improve wording, a choiceFormat does NOT have to be created with only the arrays constructor. >> - Improve throws description for input that takes pattern >> - Make Format definition more consistent with other Format classes > > src/java.base/share/classes/java/text/ChoiceFormat.java line 155: > >> 153: * "#" / "<" / "≤" >> 154: * Format: >> 155: * Any unicode characters except the Relation symbols > > Nit: since characters in Java are of Unicode code points, no need to mention `unicode` here. Thanks for the follow-up review. Fixed the nit, and updated the [CSR](https://bugs.openjdk.org/browse/JDK-8314546) to reflect all of the changes. (I used the 'Unicode' wording because the other Format classes did, I will adjust it for the other classes in this [issue](https://bugs.openjdk.org/browse/JDK-8315946) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1320340696 From iris at openjdk.org Fri Sep 8 21:14:39 2023 From: iris at openjdk.org (Iris Clark) Date: Fri, 8 Sep 2023 21:14:39 GMT Subject: RFR: 8315938: Deprecate for removal Unsafe methods that have standard APIs for many releases In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 15:54:05 GMT, Alan Bateman wrote: > There are several methods defined by sun.misc.Unsafe that have standard API equivalents for many years and releases. The change proposed here is to deprecate, for removal, the park, unpark, getLoadAverage, loadFence, storeFence, and fullFence methods. Code using these methods should move to LockSupport.park/unpark (Java 5), OperatingSystemMXBean.getSystemLoadAverage (Java 6), and VarHandles xxxFence methods (Java 9). > > The following is a summary of a search of 175973022 classes in 484751 artifacts to get a sense of the usage of these methods. > > - 1290 usages of Unsafe.park. 1195 are libraries that have re-packaged some version of ForkJoinPool, maybe from the jsr166 repo, maybe an older JDK release. In the remaining, only Ehcache stands out with 29 matches. It seems to be one usage but the library seems to copied/shaded into other artifacts. > > - 1322 usages of Unsafe.unpark. 1243 are re-packaged ForkJoinPool. 29 occurrences are Encache, again one usage but the library seems to copied/shaded into other artifacts. > > - 22 usages of Unsafe.getLoadAverage. Most of these are one usage in many published versions of Apache HBase. > > - 339 usages of Unsafe.loadFence, 1057 usages of Unsafe.storeFence, 517 usages of Unsafe.fullFence. A handful of these are libraries with copies of j.u.concurrent, the rest seem to be high performance libraries that support older JDK releases or just haven't been updated to use VarHandles yet. Happy to see these methods start their journey towards eventual removal. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15641#pullrequestreview-1618280143 From naoto at openjdk.org Fri Sep 8 21:51:27 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 8 Sep 2023 21:51:27 GMT Subject: RFR: 8041488: Locale-Dependent List Patterns [v17] In-Reply-To: References: Message-ID: > Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Made the class final, added @since tag to the nested enums ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15130/files - new: https://git.openjdk.org/jdk/pull/15130/files/19c0a201..44efb94a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=15-16 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130 PR: https://git.openjdk.org/jdk/pull/15130 From jlu at openjdk.org Fri Sep 8 23:07:50 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 8 Sep 2023 23:07:50 GMT Subject: Integrated: 8315410: Undocumented exceptions in java.text.StringCharacterIterator In-Reply-To: References: Message-ID: On Fri, 1 Sep 2023 23:12:28 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315558) which is a conformance change to document some exceptions in the specification of java.text.StringCharacterIterator. This pull request has now been integrated. Changeset: 9b0da489 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/9b0da4891527cb426093266d53e1c4e80a48376d Stats: 26 lines in 1 file changed: 13 ins; 6 del; 7 mod 8315410: Undocumented exceptions in java.text.StringCharacterIterator Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/15547 From jlu at openjdk.org Fri Sep 8 23:10:07 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 8 Sep 2023 23:10:07 GMT Subject: RFR: JDK-8315946: DecimalFormat and CompactNumberFormat do allow U+FFFE and U+FFFF in the pattern Message-ID: Please review this change which adjusts the pattern syntax specification for the two classes to represent the actual behavior. That is, U+FFFE and U+FFFF are allowed in the suffix/prefix. (Additionally; 'Unicode' is dropped from the definitions, as a Java character is composed of Unicode code points). See code below, no exception is thrown. String uFFFE = "\uFFFE"; String uFFFF = "\uFFFF"; var a = new DecimalFormat("prefixStart"+uFFFE+"0.00"+uFFFF+"SuffixEnd"); a.format(1); // returns "prefixStart?1.00?SuffixEnd" var b = new CompactNumberFormat(a.toPattern(), a.getDecimalFormatSymbols(), new String[] {""}); b.format(1); // returns "prefixStart?1?SuffixEnd" ------------- Commit messages: - Include link in DecimalFormat - Drop 'Unicode', as it is implied - init Changes: https://git.openjdk.org/jdk/pull/15648/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15648&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315946 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15648.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15648/head:pull/15648 PR: https://git.openjdk.org/jdk/pull/15648 From aefimov at openjdk.org Fri Sep 8 23:18:10 2023 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 8 Sep 2023 23:18:10 GMT Subject: RFR: 8277954: Replace use of monitors with explicit locks in the JDK LDAP provider implementation [v2] In-Reply-To: References: Message-ID: > The change proposed in this PR improves the behavior of the JDK JNDI/LDAP provider when running in a virtual thread. Currently, when an LDAP operation is performed from a virtual thread context a pinned carrier thread is detected: > > Thread[#29,ForkJoinPool-1-worker-1,5,CarrierThreads] > java.naming/com.sun.jndi.ldap.Connection.read reply(Connection.java:444) <== monitors:1 > java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:369) <== monitors:1 > java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:196) <== monitors:1 > java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2896) <== monitors:1 > > To fix that monitor usages are replaced with `j.u.c` locks. All synchronized blocks/methods have been replaced with locks even if it is only guarding memory access - the motivation behind such a decision was to avoid an analysis of scenarios where a mix of monitors and `j.u.c` locks is used. > > There are three types of mechanical changes done in this PR: > > 1. Classes with `synchronized` blocks or `synchronized` methods have been updated to include a new `ReentrantLock` field. These new fields are used to replace `synchronized` blocks/methods. > 1. classes that use notify/wait on object monitor have been updated to use `ReentrantLock.Condition`s signal/await. > 1. if one class `synchronized` on an instance of another class - the `ReentrantLock` added in item (1) was made a package-protected to give access to another class. > > With the proposed changes pinned carrier threads are no longer detected during execution of LDAP operations. > > Testing: `jdk-tier1` to `jdk-tier3`, other `jndi/ldap` regression and JCK naming tests show no failures. Aleksei Efimov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8277954_replace_synchronized_ldap - revert incorrect changes in LdapCtx.addNamingListener, formatting and (c) updates - draft version ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15526/files - new: https://git.openjdk.org/jdk/pull/15526/files/85bbe2a7..9794b094 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15526&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15526&range=00-01 Stats: 31231 lines in 922 files changed: 18653 ins; 7610 del; 4968 mod Patch: https://git.openjdk.org/jdk/pull/15526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15526/head:pull/15526 PR: https://git.openjdk.org/jdk/pull/15526 From aefimov at openjdk.org Fri Sep 8 23:18:11 2023 From: aefimov at openjdk.org (Aleksei Efimov) Date: Fri, 8 Sep 2023 23:18:11 GMT Subject: RFR: 8277954: Replace use of monitors with explicit locks in the JDK LDAP provider implementation [v2] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 14:59:38 GMT, Daniel Fuchs wrote: > Look reasonable to me. If tier2 and all jndi tests are still passing, I'm good with it. Thanks for the review Daniel. `tier1`, `tier2`, `tier3` and JNDI/LDAP JCK tests showed no failures with the change proposed here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15526#issuecomment-1712323351 From bpb at openjdk.org Fri Sep 8 23:19:38 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 8 Sep 2023 23:19:38 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v2] In-Reply-To: References: Message-ID: On Fri, 8 Sep 2023 10:00:42 GMT, Alan Bateman wrote: > The two cases that I'm wondering about are `\\\?\` and `\\\?\\UNC`. Both of these cases throw an IOE with message "Bad pathname" for `getCanonicalPath()` and `getParentFile().getCanonicalPath()` with both the mainline and with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1712327678 From liach at openjdk.org Fri Sep 8 23:51:42 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 8 Sep 2023 23:51:42 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Fri, 8 Sep 2023 21:06:25 GMT, ExE Boss wrote: >> ??? has updated the pull request incrementally with one additional commit since the last revision: >> >> lo | hi => hi | lo > > src/java.base/share/classes/java/util/HexDigits.java line 66: > >> 64: */ >> 65: @Stable >> 66: private static final short[] DIGITS; > > Maybe?it?should be?`char[]`?instead since?it?s?encoded using?unsigned 16?bit?integers. a char would confuse people that each char represents one character, while it represents 2 in fact. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320429120 From redestad at openjdk.org Sat Sep 9 06:45:40 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sat, 9 Sep 2023 06:45:40 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Fri, 8 Sep 2023 23:49:04 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/util/HexDigits.java line 66: >> >>> 64: */ >>> 65: @Stable >>> 66: private static final short[] DIGITS; >> >> Maybe?it?should be?`char[]`?instead since?it?s?encoded using?unsigned 16?bit?integers. > > a char would confuse people that each char represents one character, while it represents 2 in fact. @liach has a fair point. Either way it should be performance neutral. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320498655 From redestad at openjdk.org Sat Sep 9 07:10:45 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sat, 9 Sep 2023 07:10:45 GMT Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14] In-Reply-To: References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com> Message-ID: On Fri, 8 Sep 2023 20:36:31 GMT, ??? wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test TEST="micro:java.util.UUIDBench.toString" >> >> >> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) >> * cpu : intel xeon sapphire rapids (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 62.019 ? 0.622 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 82.998 ? 0.739 ops/us (+33.82%) >> >> >> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) >> * cpu : amd epc genoa (x64) >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 88.668 ? 0.672 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 89.229 ? 0.271 ops/us (+0.63%) >> >> >> >> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) >> * cpu : aliyun yitian 710 (aarch64) >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 49.382 ? 2.160 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 49.636 ? 1.974 ops/us (+0.51%) >> >> >> ## 4. MacBookPro M1 Pro >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 103.543 ? 0.963 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units >> +UUIDBench.toString 20000 thrpt 15 110.976 ? 0.685 ops/us (+7.17%) >> >> >> ## 5. Orange Pi 5 Plus >> >> ``` diff >> -Benchmark (size) Mode Cnt Score Error Units (baseline) >> -UUIDBench.toString 20000 thrpt 15 33.532 ? 0.396 ops/us >> >> +Benchmark (size) Mode Cnt Score Error Units (PR) >> +UUIDBench.toString 20000 thrpt 15 33.054 ? 0.190 ops/us (-4.42%) > > ??? has updated the pull request incrementally with one additional commit since the last revision: > > lo | hi => hi | lo src/java.base/share/classes/java/util/HexDigits.java line 42: > 40: * hex relative to its index, for example:

> 41: * 

> 42:      *       0 -> '00' -> '0' | ('0' << 8) -> 0x3030

AFAICT this is now a copy of `StringLatin1::PACKED_DIGITS`, which might be fine. The comment to `StringLatin1::PACKED_DIGITS` seem wrong, though? I think that needs a re-examination (in this or in a separate PR)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320502452

From redestad at openjdk.org  Sat Sep  9 07:13:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 9 Sep 2023 07:13:42 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
Message-ID: <52mrJxNrOVzcA2TBB9CKdOvrxfVAaNbWNfih-pLDt2Y=.933bdb07-bd96-4b71-a004-89f76046e6b1@github.com>

On Sat, 9 Sep 2023 07:08:07 GMT, Claes Redestad  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   lo | hi => hi | lo
>
> src/java.base/share/classes/java/util/HexDigits.java line 42:
> 
>> 40:      * hex relative to its index, for example:

>> 41:      * 
>> 42:      *       0 -> '00' -> '0' | ('0' << 8) -> 0x3030
> 
> AFAICT this is now a copy of `StringLatin1::PACKED_DIGITS`, which might be fine. The comment to `StringLatin1::PACKED_DIGITS` seem wrong, though? I think that needs a re-examination (in this or in a separate PR)

Perhaps you could extract the `digitPair` method you're adding in #15555 to a separate PR and use that to remove `HexDigits::DIGITS`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320502947

From duke at openjdk.org  Sat Sep  9 07:58:22 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 9 Sep 2023 07:58:22 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v12]
In-Reply-To: 
References: 
Message-ID: <73sIX1lPADQO8KO4WGCLlgklFbCy1RqgzD0yIdXKLsk=.ae5067c7-e3cd-4ecf-88f3-033f3fa2891d@github.com>

> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal.
> 
> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance.
> 
> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering.
> 
> The performance data is as follows: 
> 
> ## 1. benchmark script
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.math.BigDecimals.*ToPlainString"
> make test TEST="micro:java.math.BigDecimals.*ToEngineering"
> 
> 
> ## 2. benchmark environment
> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i)
> * cpu intel xeon sapphire rapids (x64)
> 
> ## 3. benchmark result
> 
> -BigDecimals.testHugeToPlainString         avgt   15   188.691 ?  0.822  ns/op  (baseline)
> -BigDecimals.testLargeToPlainString        avgt   15    36.656 ?  0.065  ns/op
> -BigDecimals.testSmallToPlainString        avgt   15    34.342 ?  0.068  ns/op
> -BigDecimals.testToPlainString             avgt   15  1719.494 ? 24.886  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
> +BigDecimals.testHugeToPlainString         avgt   15   133.972 ?  0.328  ns/op (+40.84%)
> +BigDecimals.testLargeToPlainString        avgt   15    14.957 ?  0.047  ns/op (145.07%)
> +BigDecimals.testSmallToPlainString        avgt   15    12.045 ?  0.036  ns/op (+185.11)
> +BigDecimals.testToPlainString             avgt   15  1643.500 ?  3.217  ns/op (+4.62%)
> 
> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
> -BigDecimals.testHugeToEngineeringString   avgt   15   207.621 ?  5.018  ns/op
> -BigDecimals.testLargeToEngineeringString  avgt   15    35.658 ?  3.144  ns/op
> -BigDecimals.testSmallToEngineeringString  avgt   15    15.142 ?  0.053  ns/op
> -BigDecimals.testToEngineeringString       avgt   15  1813.959 ? 12.842  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
> +BigDecimals.testHugeToEngineeringString   avgt   15   142.110 ?  0.987  ns/op (+45.09%)
> +BigDecimals.testLargeToEngineeringString  avgt   15    12.509 ?  0.056  ns/op (+185.05%)
> +BigDecimals.testSmallToEngineer...

??? has updated the pull request with a new target base 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 optimization_for_decimal_to_string
 - fix scale 19 error & add testcases
 - bug fix & add testcases
 - remove jla.newStringLatin1NoRepl
 - rename jla.digit to digitPair
 - fix adjusted >= Integer.MAX_VALUE
 - Continue to optimize and reduce duplicate code
 - Merge branch 'master' into optimization_for_decimal_to_string_2
 - add testcase & bug fix
 - Merge branch 'master' into optimization_for_decimal_to_string
 - ... and 4 more: https://git.openjdk.org/jdk/compare/af39d8d4...33f8688d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15555/files
  - new: https://git.openjdk.org/jdk/pull/15555/files/562869d5..33f8688d

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

  Stats: 8635 lines in 272 files changed: 3793 ins; 4418 del; 424 mod
  Patch: https://git.openjdk.org/jdk/pull/15555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555

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

From duke at openjdk.org  Sat Sep  9 08:02:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 9 Sep 2023 08:02:41 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: <52mrJxNrOVzcA2TBB9CKdOvrxfVAaNbWNfih-pLDt2Y=.933bdb07-bd96-4b71-a004-89f76046e6b1@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
 <52mrJxNrOVzcA2TBB9CKdOvrxfVAaNbWNfih-pLDt2Y=.933bdb07-bd96-4b71-a004-89f76046e6b1@github.com>
Message-ID: 

On Sat, 9 Sep 2023 07:11:01 GMT, Claes Redestad  wrote:

>> src/java.base/share/classes/java/util/HexDigits.java line 42:
>> 
>>> 40:      * hex relative to its index, for example:

>>> 41:      * 
>>> 42:      *       0 -> '00' -> '0' | ('0' << 8) -> 0x3030
>> 
>> AFAICT this is now a copy of `StringLatin1::PACKED_DIGITS`, which might be fine. The comment to `StringLatin1::PACKED_DIGITS` seem wrong, though? I think that needs a re-examination (in this or in a separate PR)
>
> Perhaps you could extract the `digitPair` method you're adding in #15555 to a separate PR and use that to remove `HexDigits::DIGITS`?

Please help me create an issue, and I will submit a new PR to modify it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320510252

From alanb at openjdk.org  Sat Sep  9 08:35:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Sep 2023 08:35:47 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 8 Sep 2023 01:07:17 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: Handle "\\?\UNC"; add bad paths to test

For `\\\?\`, the normalization will drop the trailing slash so the path string is actually `\\\?`. I that that case is okay.

For input such as `\\\?\\foo` and `\\\?\\C:`, the stripping results in a relative path, `foo` and `C:` in these examples, which means the canonicalize code is starting with a relative path. We have to be careful here as the path has always been make absolute before attempting to canonicalize.

For `\\\?\\UNC` and `\\\?\\UNC\`, the stripping means these will be treated as `\`, which is the root directory of the current volume. I know these will fail with "The network path was not path" but I can't help thinking it would reject/throw early.

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

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

From alanb at openjdk.org  Sat Sep  9 08:42:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Sep 2023 08:42:40 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock. [v2]
In-Reply-To: 
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 
 
 
 
 <_b4wRbfmijSU1QL-bMrBvy5wQoaQp8fFO96SdOuE438=.923f52e6-b930-47c4-8e08-e7b299722657@github.com>
 
 
 
Message-ID: 

On Fri, 8 Sep 2023 18:45:02 GMT, Brent Christian  wrote:

> I would also like to see what a FileChannel implementation looks like. Am I right that this would allow the `prefs` native library to be removed entirely?

Yes. FileChannel.open can be called with the file permissions to atomically set when creating the lock file, and the 3-arg lock method can be used for both shared and exclusive locking. The usages of chmod would change to Files.setPosixFilePermissions. It should be quick to try to see if there are any issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1712458404

From dl at openjdk.org  Sat Sep  9 12:42:29 2023
From: dl at openjdk.org (Doug Lea)
Date: Sat, 9 Sep 2023 12:42:29 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v27]
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:

  Always help terminate when stopping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/0eadfc73..3e103e09

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

  Stats: 18 lines in 1 file changed: 2 ins; 4 del; 12 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 lancea at openjdk.org  Sat Sep  9 14:41:12 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 9 Sep 2023 14:41:12 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation
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 not set to 0xFFFFFFFF
-- disk starting number is not 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

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

Commit messages:
 - Clean up some minor formatting issues
 - Additional Zip64 extra header validation

Changes: https://git.openjdk.org/jdk/pull/15650/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15650&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314891
  Stats: 544 lines in 3 files changed: 513 ins; 7 del; 24 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 duke at openjdk.org  Sat Sep  9 16:17:57 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 9 Sep 2023 16:17:57 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v13]
In-Reply-To: 
References: 
Message-ID: 

> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal.
> 
> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance.
> 
> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering.
> 
> The performance data is as follows: 
> 
> ## 1. benchmark script
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.math.BigDecimals.*ToPlainString"
> make test TEST="micro:java.math.BigDecimals.*ToEngineering"
> 
> 
> ## 2. benchmark environment
> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i)
> * cpu intel xeon sapphire rapids (x64)
> 
> ## 3. benchmark result
> 
> -BigDecimals.testHugeToPlainString         avgt   15   188.691 ?  0.822  ns/op  (baseline)
> -BigDecimals.testLargeToPlainString        avgt   15    36.656 ?  0.065  ns/op
> -BigDecimals.testSmallToPlainString        avgt   15    34.342 ?  0.068  ns/op
> -BigDecimals.testToPlainString             avgt   15  1719.494 ? 24.886  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
> +BigDecimals.testHugeToPlainString         avgt   15   133.972 ?  0.328  ns/op (+40.84%)
> +BigDecimals.testLargeToPlainString        avgt   15    14.957 ?  0.047  ns/op (145.07%)
> +BigDecimals.testSmallToPlainString        avgt   15    12.045 ?  0.036  ns/op (+185.11)
> +BigDecimals.testToPlainString             avgt   15  1643.500 ?  3.217  ns/op (+4.62%)
> 
> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
> -BigDecimals.testHugeToEngineeringString   avgt   15   207.621 ?  5.018  ns/op
> -BigDecimals.testLargeToEngineeringString  avgt   15    35.658 ?  3.144  ns/op
> -BigDecimals.testSmallToEngineeringString  avgt   15    15.142 ?  0.053  ns/op
> -BigDecimals.testToEngineeringString       avgt   15  1813.959 ? 12.842  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
> +BigDecimals.testHugeToEngineeringString   avgt   15   142.110 ?  0.987  ns/op (+45.09%)
> +BigDecimals.testLargeToEngineeringString  avgt   15    12.509 ?  0.056  ns/op (+185.05%)
> +BigDecimals.testSmallToEngineer...

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

  improved huge BigDecimal to string

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15555/files
  - new: https://git.openjdk.org/jdk/pull/15555/files/33f8688d..a3035e8f

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

  Stats: 79 lines in 2 files changed: 68 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/15555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555

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

From alanb at openjdk.org  Sat Sep  9 18:38:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Sep 2023 18:38:40 GMT
Subject: RFR: 8315373: Change VirtualThread to unmount after freezing,
 re-mount before thawing [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <-DJpvOsSYGfCpkb7SjWJSfHkX4J7dvIh2tjls_1an5o=.9281d4d3-8286-4f9e-b1b2-b4c0887b81e0@github.com>

On Wed, 6 Sep 2023 05:01:38 GMT, Serguei Spitsyn  wrote:

> The fix looks okay to me. From JVMTI point of view this transition is hidden, so no inconsistency can be observed. However, I wonder if the AsyncGetStackTraces may have similar issue as the JFR had. Unfortunately we do not have good test coverage to rely on.

Thanks Serguei. When testing, I had one failure (that I couldn't duplicate) of serviceability/jvmti/stress/StackTrace/NotSuspended/GetStackTraceNotSuspendedStressTest.java with -Xcomp XX:CompileThreshold=100 -XX:+TieredCompilation -XX:+DeoptimizeALot. It's looking for the stack trace of the enter method but printed the stack trace of the carrier (not the virtual thread) when it failed. I'll create a bug for that as as there's a lurking issue there with the test, GetStackTrace or the non-standard/extension function GetVirtualThread.

AsyncGetStackTraces doesn't know about stack chunks so it's not reliable when a virtual thread is mounted.

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

PR Comment: https://git.openjdk.org/jdk/pull/15492#issuecomment-1712573937

From dl at openjdk.org  Sun Sep 10 11:43:22 2023
From: dl at openjdk.org (Doug Lea)
Date: Sun, 10 Sep 2023 11:43:22 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v28]
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:

  Simplify signalling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/3e103e09..31a1f34e

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

  Stats: 42 lines in 1 file changed: 3 ins; 14 del; 25 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 alanb at openjdk.org  Sun Sep 10 15:00:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 10 Sep 2023 15:00:53 GMT
Subject: Integrated: 8315373: Change VirtualThread to unmount after freezing, 
 re-mount before thawing
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman  wrote:

> In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM.
> 
> The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition.
> 
> Testing: tier1-5

This pull request has now been integrated.

Changeset: 9a83d558
Author:    Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/9a83d55887e5e3a0a2e1e020c6ccb91604672358
Stats:     49 lines in 3 files changed: 12 ins; 17 del; 20 mod

8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

Reviewed-by: pchilanomate, mgronlun, sspitsyn

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

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

From redestad at openjdk.org  Sun Sep 10 15:22:49 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 10 Sep 2023 15:22:49 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
 <52mrJxNrOVzcA2TBB9CKdOvrxfVAaNbWNfih-pLDt2Y=.933bdb07-bd96-4b71-a004-89f76046e6b1@github.com>
 
Message-ID: 

On Sat, 9 Sep 2023 07:59:30 GMT, ???  wrote:

>> Perhaps you could extract the `digitPair` method you're adding in #15555 to a separate PR and use that to remove `HexDigits::DIGITS`?
>
> Please help me create an issue, and I will submit a new PR to modify it.

Filed https://bugs.openjdk.org/browse/JDK-8315968 - we should also get @JimLaskey to weigh in here (who's recently authored the `java.util.Digits` code). Tl;dr: I think it'd be good to consolidate and share the code to produce these packed digit pairs.

Also note that there might be some issues on big-endian systems with recent changes, so let's figure that out first: https://bugs.openjdk.org/browse/JDK-8310929

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320788026

From duke at openjdk.org  Sun Sep 10 16:01:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 16:01:41 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
 <52mrJxNrOVzcA2TBB9CKdOvrxfVAaNbWNfih-pLDt2Y=.933bdb07-bd96-4b71-a004-89f76046e6b1@github.com>
 
 
Message-ID: 

On Sun, 10 Sep 2023 15:19:51 GMT, Claes Redestad  wrote:

>> Please help me create an issue, and I will submit a new PR to modify it.
>
> Filed https://bugs.openjdk.org/browse/JDK-8315968 - we should also get @JimLaskey to weigh in here (who's recently authored the `java.util.Digits` code). Tl;dr: I think it'd be good to consolidate and share the code to produce these packed digit pairs.
> 
> Also note that there might be some issues on big-endian systems with recent changes, so let's figure that out first: https://bugs.openjdk.org/browse/JDK-8310929

https://github.com/wenshao/jdk/tree/fix_14699_big_endian

I have a [branch](https://github.com/wenshao/jdk/tree/fix_14699_big_endian) ready to fix the big endian issue and need someone to create an issue

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320793606

From duke at openjdk.org  Sun Sep 10 16:22:14 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 16:22:14 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS
Message-ID: 

Some codes in core libs are duplicated, including:
java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
java.util.DecimalDigits::size -> java.lang.Long.stringSize

We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
https://github.com/openjdk/jdk/pull/15555

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

Commit messages:
 - reduce duplicate

Changes: https://git.openjdk.org/jdk/pull/15651/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315968
  Stats: 114 lines in 3 files changed: 73 ins; 33 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From rriggs at openjdk.org  Sun Sep 10 16:43:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sun, 10 Sep 2023 16:43:36 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS
In-Reply-To: 
References: 
Message-ID: 

On Sun, 10 Sep 2023 16:15:01 GMT, ???  wrote:

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

Instead of packing more stuff into SharedSecrets, how about moving some common utilities into package jdk.internal.util or a new package jdk.internal.string.
For example, Digits, HexDigits, DecimalDigits, OctalDigits.
That would make access better without the overhead shared secrets.

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1712866040

From duke at openjdk.org  Sun Sep 10 16:50:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 16:50:42 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
 <52mrJxNrOVzcA2TBB9CKdOvrxfVAaNbWNfih-pLDt2Y=.933bdb07-bd96-4b71-a004-89f76046e6b1@github.com>
 
 
 
Message-ID: <57QzgEYFlYbzzknibXJERb-5YP761iMwA7XCkm9pUhY=.64dde947-264c-4abf-a509-f5bd34429e17@github.com>

On Sun, 10 Sep 2023 15:59:05 GMT, ???  wrote:

>> Filed https://bugs.openjdk.org/browse/JDK-8315968 - we should also get @JimLaskey to weigh in here (who's recently authored the `java.util.Digits` code). Tl;dr: I think it'd be good to consolidate and share the code to produce these packed digit pairs.
>> 
>> Also note that there might be some issues on big-endian systems with recent changes, so let's figure that out first: https://bugs.openjdk.org/browse/JDK-8310929
>
> https://github.com/wenshao/jdk/tree/fix_14699_big_endian
> 
> I have a [branch](https://github.com/wenshao/jdk/tree/fix_14699_big_endian) ready to fix the big endian problem and need someone to create an issue

https://github.com/openjdk/jdk/pull/15652

I've submitted a PR to fix the big endian problem

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1320813162

From redestad at openjdk.org  Sun Sep 10 17:28:37 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 10 Sep 2023 17:28:37 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS
In-Reply-To: 
References: 
Message-ID: 

On Sun, 10 Sep 2023 16:15:01 GMT, ???  wrote:

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

Yes, moving java.util.Digits to jdk.internal.util was what I had in mind, too. SharedSecrets are only necessary when we have things that need to stay package-private, such as member functions on String. Static utilities like this are generally easier to maintain when they are public but in a non-exported package like jdk.internal.util.

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1712887622

From duke at openjdk.org  Sun Sep 10 17:59:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 17:59:10 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v2]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  move java.util.DecimalDigits to jdk.internal.util.DecimalDigits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/41044955..518ccb75

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

  Stats: 565 lines in 12 files changed: 287 ins; 261 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From duke at openjdk.org  Sun Sep 10 18:02:05 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 18:02:05 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929
Message-ID: 

https://bugs.openjdk.org/browse/JDK-8310929

@TheRealMDoerr Feedback:


We're getting test failures on AIX:
compiler/intrinsics/Test8215792.java
compiler/intrinsics/string/TestStringIntrinsics.java
runtime/CompactStrings/TestMethodNames.java
runtime/StringIntrinsic/StringIndexOfChar.java
Is there a problem with Big Endian?

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

Commit messages:
 - fix PR #14699 big endian error

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

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

From redestad at openjdk.org  Sun Sep 10 18:02:05 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 10 Sep 2023 18:02:05 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929
In-Reply-To: 
References: 
Message-ID: <5JWGLQplg127hGH453RvC24pp__ajEFtPRwjixCn-d4=.0c5b5099-5f97-4948-99c1-d894bf827100@github.com>

On Sun, 10 Sep 2023 16:39:30 GMT, ???  wrote:

> https://bugs.openjdk.org/browse/JDK-8310929
> 
> @TheRealMDoerr Feedback:
> 
> 
> We're getting test failures on AIX:
> compiler/intrinsics/Test8215792.java
> compiler/intrinsics/string/TestStringIntrinsics.java
> runtime/CompactStrings/TestMethodNames.java
> runtime/StringIntrinsic/StringIndexOfChar.java
> Is there a problem with Big Endian?

Filed https://bugs.openjdk.org/browse/JDK-8315970 for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1712886783

From rriggs at openjdk.org  Sun Sep 10 18:13:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sun, 10 Sep 2023 18:13:47 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v2]
In-Reply-To: 
References: 
 
Message-ID: <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com>

On Sun, 10 Sep 2023 17:59:10 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move java.util.DecimalDigits to jdk.internal.util.DecimalDigits

This would cleaner and easier to review, if you moved the classes together and did not refactor the functions. Only include the dependencies. Update the functions in a separate PR.  (We can retitle the issue to match).

src/java.base/share/classes/java/lang/Long.java line 45:

> 43: import static java.lang.String.UTF16;
> 44: 
> 45: import static jdk.internal.util.DecimalDigits.stringSize;

Please don't use static import for methods. It makes it much harder to find where they come from.

src/java.base/share/classes/java/util/Digits.java line 36:

> 34:  * @since 21
> 35:  */
> 36: sealed interface Digits permits HexDigits, OctalDigits {

Don't break up the trio, move all three classes and the interface to jdk.internal.util.
I don't see the value in the INSTANCE values but keep it intact.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1618893492
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320839379
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320839614

From rriggs at openjdk.org  Sun Sep 10 18:24:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sun, 10 Sep 2023 18:24:36 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929
In-Reply-To: 
References: 
Message-ID: 

On Sun, 10 Sep 2023 16:39:30 GMT, ???  wrote:

> https://bugs.openjdk.org/browse/JDK-8310929
> 
> @TheRealMDoerr Feedback:
> 
> 
> We're getting test failures on AIX:
> compiler/intrinsics/Test8215792.java
> compiler/intrinsics/string/TestStringIntrinsics.java
> runtime/CompactStrings/TestMethodNames.java
> runtime/StringIntrinsic/StringIndexOfChar.java
> Is there a problem with Big Endian?

I'd suggest backing out the whole commit and resumitting after the fix and more complete testing.

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

PR Review: https://git.openjdk.org/jdk/pull/15652#pullrequestreview-1618895642

From duke at openjdk.org  Sun Sep 10 18:46:21 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 18:46:21 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v3]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

??? has updated the pull request incrementally with two additional commits since the last revision:

 - move java.util.OctalDigits to jdk.internal.util.OctalDigits
 - none static import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/518ccb75..a2cf492e

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

  Stats: 183 lines in 7 files changed: 79 ins; 95 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From duke at openjdk.org  Sun Sep 10 18:46:24 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 18:46:24 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v2]
In-Reply-To: <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com>
References: 
 
 <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com>
Message-ID: 

On Sun, 10 Sep 2023 18:08:44 GMT, Roger Riggs  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move java.util.DecimalDigits to jdk.internal.util.DecimalDigits
>
> src/java.base/share/classes/java/util/Digits.java line 36:
> 
>> 34:  * @since 21
>> 35:  */
>> 36: sealed interface Digits permits HexDigits, OctalDigits {
> 
> Don't break up the trio, move all three classes and the interface to jdk.internal.util.
> I don't see the value in the INSTANCE values but keep it intact.

HexDigits I will change after the PR #14745 is merged,  Can you add comment /sponsor for me?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320843201

From duke at openjdk.org  Sun Sep 10 18:46:25 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 18:46:25 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v2]
In-Reply-To: 
References: 
 
 <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com>
 
Message-ID: 

On Sun, 10 Sep 2023 18:37:20 GMT, ???  wrote:

>> src/java.base/share/classes/java/util/Digits.java line 36:
>> 
>>> 34:  * @since 21
>>> 35:  */
>>> 36: sealed interface Digits permits HexDigits, OctalDigits {
>> 
>> Don't break up the trio, move all three classes and the interface to jdk.internal.util.
>> I don't see the value in the INSTANCE values but keep it intact.
>
> HexDigits I will change after the PR #14745 is merged,  Can you add comment /sponsor for me?

I want to remove the Digits interface and use static methods

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320843342

From duke at openjdk.org  Sun Sep 10 18:46:37 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 18:46:37 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929
In-Reply-To: 
References: 
Message-ID: 

On Sun, 10 Sep 2023 16:39:30 GMT, ???  wrote:

> https://bugs.openjdk.org/browse/JDK-8310929
> 
> @TheRealMDoerr Feedback:
> 
> 
> We're getting test failures on AIX:
> compiler/intrinsics/Test8215792.java
> compiler/intrinsics/string/TestStringIntrinsics.java
> runtime/CompactStrings/TestMethodNames.java
> runtime/StringIntrinsic/StringIndexOfChar.java
> Is there a problem with Big Endian?

I don't have a big endian environment so I can't test it. I need help from @TheRealMDoerr

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1712908936

From rriggs at openjdk.org  Sun Sep 10 18:57:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sun, 10 Sep 2023 18:57:44 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
Message-ID: 

On Fri, 8 Sep 2023 20:36:31 GMT, ???  wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.toString"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lo | hi => hi | lo

Given the endian-ness issues with https://git.openjdk.org/jdk/pull/14699.
I'll need to run a more complete set of tests first.

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1712910837

From duke at openjdk.org  Sun Sep 10 20:04:53 2023
From: duke at openjdk.org (iaroslavski)
Date: Sun, 10 Sep 2023 20:04:53 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v19]
In-Reply-To: 
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 
Message-ID: 

On Sun, 12 Mar 2023 21:28:59 GMT, iaroslavski  wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Use uninitialized array for buffers

next version is under developing

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

PR Comment: https://git.openjdk.org/jdk/pull/3938#issuecomment-1712924581

From redestad at openjdk.org  Sun Sep 10 21:20:47 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 10 Sep 2023 21:20:47 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v2]
In-Reply-To: <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com>
References: 
 
 <69_DWQGgCUgRsz-sHdEF59CU56qJ_Cc1I2phL-6FHVM=.e61cb9f8-feed-4621-826a-62c1d8239315@github.com>
Message-ID: 

On Sun, 10 Sep 2023 18:08:44 GMT, Roger Riggs  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move java.util.DecimalDigits to jdk.internal.util.DecimalDigits
>
> src/java.base/share/classes/java/util/Digits.java line 36:
> 
>> 34:  * @since 21
>> 35:  */
>> 36: sealed interface Digits permits HexDigits, OctalDigits {
> 
> Don't break up the trio, move all three classes and the interface to jdk.internal.util.
> I don't see the value in the INSTANCE values but keep it intact.

I agree with @RogerRiggs that these should be moved together and with as few changes as possible. We can do redesigns in follow-ups.

I'd be OK with adding static variants of each method as needed, leaving the instance methods unchanged. 

I'll note that these `java.util.Digits` came in as part of what's currently a preview feature (https://openjdk.org/jeps/430) and the author (@JimLaskey) might have plans that requires an implementation that could be passed around in the final version - so design changes should be coordinated with him.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320862759

From redestad at openjdk.org  Sun Sep 10 22:30:36 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 10 Sep 2023 22:30:36 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929
In-Reply-To: 
References: 
Message-ID: 

On Sun, 10 Sep 2023 16:39:30 GMT, ???  wrote:

> https://bugs.openjdk.org/browse/JDK-8310929
> 
> @TheRealMDoerr Feedback:
> 
> 
> We're getting test failures on AIX:
> compiler/intrinsics/Test8215792.java
> compiler/intrinsics/string/TestStringIntrinsics.java
> runtime/CompactStrings/TestMethodNames.java
> runtime/StringIntrinsic/StringIndexOfChar.java
> Is there a problem with Big Endian?

src/java.base/share/classes/java/lang/StringUTF16.java line 1632:

> 1630:     private static int inflatePacked(int v) {
> 1631:         int packed = (int) StringLatin1.PACKED_DIGITS[v];
> 1632:         return ((packed & 0xFF) << HI_BYTE_SHIFT)

I'm not sure this is correct.

Compare `StringUTF16::putChar` where these constants are used to shift _right_ to extract the equivalent byte from a value:

        val[index++] = (byte)(c >> HI_BYTE_SHIFT);
        val[index]   = (byte)(c >> LO_BYTE_SHIFT);

I.e., when inflating a `byte` `0xaa` to a `char` we end up with 0xaa00 on big-endian.

Since `HI_BYTE_SHIFT` is 8 on big-endian and 0 on little-endian I guess this might work:

```return ((packed & 0xFF) << 16 + HI_BYTE_SHIFT) | ((packed & 0xFF00) << HI_BYTE_SHIFT)```

.. but we really need to prototype and test this out thoroughly on a big-endian system. I second @RogerRiggs notion that the best course of action right now is to back out #14699 and redo it with big-endianness issues resolved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15652#discussion_r1320874615

From vpetko at openjdk.org  Sun Sep 10 23:23:47 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Sun, 10 Sep 2023 23:23:47 GMT
Subject: Integrated: 8314491: Linux: jexec launched via PATH fails to find java
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Aug 2023 10:06:19 GMT, Vladimir Petko  wrote:

> 8314491: Linux: jexec launched via PATH fails to find java

This pull request has now been integrated.

Changeset: dab1c213
Author:    Vladimir Petko 
Committer: David Holmes 
URL:       https://git.openjdk.org/jdk/commit/dab1c213fd2760686a7bf3fc8838f4a21056a954
Stats:     38 lines in 2 files changed: 24 ins; 8 del; 6 mod

8314491: Linux: jexec launched via PATH fails to find java

Reviewed-by: dholmes, rriggs

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

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

From duke at openjdk.org  Sun Sep 10 23:54:37 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 23:54:37 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929
In-Reply-To: 
References: 
Message-ID: 

On Sun, 10 Sep 2023 16:39:30 GMT, ???  wrote:

> https://bugs.openjdk.org/browse/JDK-8310929
> 
> @TheRealMDoerr Feedback:
> 
> 
> We're getting test failures on AIX:
> compiler/intrinsics/Test8215792.java
> compiler/intrinsics/string/TestStringIntrinsics.java
> runtime/CompactStrings/TestMethodNames.java
> runtime/StringIntrinsic/StringIndexOfChar.java
> Is there a problem with Big Endian?

Could it be caused by using VarHandle/ByteArrayLittleEndian?

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1712975644

From duke at openjdk.org  Sun Sep 10 23:54:39 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 10 Sep 2023 23:54:39 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 10 Sep 2023 22:27:48 GMT, Claes Redestad  wrote:

>> https://bugs.openjdk.org/browse/JDK-8310929
>> 
>> @TheRealMDoerr Feedback:
>> 
>> 
>> We're getting test failures on AIX:
>> compiler/intrinsics/Test8215792.java
>> compiler/intrinsics/string/TestStringIntrinsics.java
>> runtime/CompactStrings/TestMethodNames.java
>> runtime/StringIntrinsic/StringIndexOfChar.java
>> Is there a problem with Big Endian?
>
> src/java.base/share/classes/java/lang/StringUTF16.java line 1632:
> 
>> 1630:     private static int inflatePacked(int v) {
>> 1631:         int packed = (int) StringLatin1.PACKED_DIGITS[v];
>> 1632:         return ((packed & 0xFF) << HI_BYTE_SHIFT)
> 
> I'm not sure this is correct.
> 
> Compare `StringUTF16::putChar` where these constants are used to shift _right_ to extract the equivalent byte from a value:
> 
>         val[index++] = (byte)(c >> HI_BYTE_SHIFT);
>         val[index]   = (byte)(c >> LO_BYTE_SHIFT);
> 
> I.e., when inflating a `byte` `0xaa` to a `char` encoded into a `byte[]` we end up with `0xaa00` on big-endian. Inflating a `short` literal `0xaabb` encoding two chars logically I think will need to consider each byte in isolation, ending up with `0xaa00bb00` (in little-endian notation). Or maybe it's `0xbb00aa00`. Ugh.. 
> 
> Since `HI_BYTE_SHIFT` is 8 on big-endian and 0 on little-endian I guess this might just work:
> 
> ```return ((packed & 0xFF) << 16 + HI_BYTE_SHIFT) | ((packed & 0xFF00) << HI_BYTE_SHIFT)```
> 
> .. but we really need to re-examine, prototype and test this out thoroughly on a big-endian system. I second @RogerRiggs notion that the best course of action right now is to back out #14699 and redo it with big-endianness issues resolved.

I'm also not sure if this PR is correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15652#discussion_r1320889161

From duke at openjdk.org  Mon Sep 11 00:17:32 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 00:17:32 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v4]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  move java.util.Digits/HexDigits to jdk.internal.util.Digits/HexDigits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/a2cf492e..3d4fa486

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

  Stats: 47 lines in 6 files changed: 31 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From duke at openjdk.org  Mon Sep 11 01:12:25 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 01:12:25 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v5]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  remove java.util.Digits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/3d4fa486..0586c64f

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

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

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

From yyang at openjdk.org  Mon Sep 11 01:35:50 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 11 Sep 2023 01:35:50 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 11 Sep 2023 01:12:25 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove java.util.Digits

src/java.base/share/classes/java/lang/Integer.java line 459:

> 457:     }
> 458: 
> 459:     /**

Would better to update related comments as well

https://github.com/openjdk/jdk/blob/d2e11593006dc32fb8ebbaf12488b8758c8a19ee/src/hotspot/share/opto/stringopts.cpp#L1163-L1165

There are several occurrences in stringopt phase, grep to find them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1320912610

From duke at openjdk.org  Mon Sep 11 04:00:34 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 04:00:34 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v6]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

??? has updated the pull request incrementally with two additional commits since the last revision:

 - remove duplicate stringSize
 - update related comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/0586c64f..ebcecc34

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

  Stats: 15 lines in 2 files changed: 2 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From david.holmes at oracle.com  Mon Sep 11 05:22:19 2023
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Sep 2023 15:22:19 +1000
Subject: Java 21 clinit deadlock
In-Reply-To: 
References: 
Message-ID: <77f901c7-5bb8-4703-8c64-b331913516b6@oracle.com>

On 8/09/2023 12:38 am, Simone Bordet wrote:
> Hello,
> 
> We switched the Jetty builds to Java 21 a while ago, and they randomly
> fail with a hard deadlock during class initialization.
> 
> We tried to understand if we were doing something wrong, but the code
> compiles fine, and at first glance there seems to be nothing wrong
> with it, but it may well be a popular Java puzzler that I am not aware
> of :)
> 
> We did not see these failures with Java 20, and we do not see them with Java 17.
> 
> I was wondering if something changed in Java 21 to cause this deadlock?

I've looked at the dump and there is no sign that the MutableHttpFields 
is actively in use. It suggests to me that class initialization has 
failed but the class state has not been correctly updated and the 
waiters released. There were some changes in JDK 21 about how failures 
in this area were handled, so it is possible I/we got something wrong. 
Is it possible to try running this with additional logging enabled e.g.

-Xlog:class+init=debug -Xlog:exceptions=debug

> I hope this is the right mailing list for this problem.
> If not, please let me know.

It may well be a hotspot-runtime-dev issue

Thanks,
David
-----

> I am an OpenJDK author so I can open an issue about this, but I don't
> have a reproducer, since it seems a race condition happening randomly.
> 
> Below you can find more details about this deadlock.
> 
> Thanks!
> 
> ----
> 
> Taking a thread dump we see one thread in this state:
> 
> java.lang.Thread.State: RUNNABLE
> at org.eclipse.jetty.http.HttpFields.build(org.eclipse.jetty.http at 12.0.2-SNAPSHOT/HttpFields.java:76)
> - waiting on the Class initialization monitor for
> org.eclipse.jetty.http.MutableHttpFields
> at org.eclipse.jetty.http.HttpFields.(org.eclipse.jetty.http at 12.0.2-SNAPSHOT/HttpFields.java:67)
> "ForkJoinPool-1-worker-1" #23 [1457161] daemon prio=5 os_prio=0
> cpu=320.77ms elapsed=8870.98s allocated=18414K defined_classes=928
> tid=0x00007f6ec0c6a6f0 nid=1457161 waiting on condition
> [0x00007f6e91ffb000]
> 
> And other threads are in this state (or similar -- the bottom frame is
> different but still triggering the clinit of HttpFields):
> 
> java.lang.Thread.State: RUNNABLE
> at org.eclipse.jetty.http.HttpTester.parseResponse(org.eclipse.jetty.http at 12.0.2-SNAPSHOT/HttpTester.java:274)
> - waiting on the Class initialization monitor for
> org.eclipse.jetty.http.HttpFields
> at org.eclipse.jetty.http.HttpTester.parseResponse(org.eclipse.jetty.http at 12.0.2-SNAPSHOT/HttpTester.java:261)
> "ForkJoinPool-1-worker-2" #24 [1457162] daemon prio=5 os_prio=0
> cpu=136.15ms elapsed=8870.96s allocated=3303K defined_classes=340
> tid=0x00007f6e4c01ddb0 nid=1457162 waiting on condition
> [0x00007f6e91efc000]
> 
> Class hierarchy:
> 
> MutableHttpFields implements HttpFields.Mutable
> HttpFields.Mutable extends HttpFields
> 
> Full thread dump:
> https://gist.github.com/olamy/7e883adcf51b2410337abfa775a79a0b
> 
> Code:
> https://github.com/eclipse/jetty.project/blob/jetty-12.0.1/jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpFields.java
> 

From aturbanov at openjdk.org  Mon Sep 11 06:28:58 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 11 Sep 2023 06:28:58 GMT
Subject: RFR: 8315973: Remove unused fields from ThreadLocalRandom
Message-ID: 

These messages were used before [JDK-8248862](https://bugs.openjdk.org/browse/JDK-8248862)

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

Commit messages:
 - [PATCH] Remove unused fields from ThreadLocalRandom

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

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

From pminborg at openjdk.org  Mon Sep 11 06:34:41 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Sep 2023 06:34:41 GMT
Subject: RFR: 8315938: Deprecate for removal Unsafe methods that have
 standard APIs for many releases
In-Reply-To: 
References: 
Message-ID: 

On Fri, 8 Sep 2023 15:54:05 GMT, Alan Bateman  wrote:

> There are several methods defined by sun.misc.Unsafe that have standard API equivalents for many years and releases. The change proposed here is to deprecate, for removal, the park, unpark, getLoadAverage, loadFence, storeFence, and fullFence methods. Code using these methods should move to LockSupport.park/unpark (Java 5), OperatingSystemMXBean.getSystemLoadAverage (Java 6), and VarHandles xxxFence methods (Java 9).
> 
> The following is a summary of a search of 175973022 classes in 484751 artifacts to get a sense of the usage of these methods.
> 
> - 1290 usages of Unsafe.park. 1195 are libraries that have re-packaged some version of ForkJoinPool, maybe from the jsr166 repo, maybe an older JDK release. In the remaining, only Ehcache stands out with 29 matches. It seems to be one usage but the library seems to copied/shaded into other artifacts.
> 
> - 1322 usages of Unsafe.unpark. 1243 are re-packaged ForkJoinPool. 29 occurrences are Encache, again one usage but the library seems to copied/shaded into other artifacts.
> 
> - 22 usages of Unsafe.getLoadAverage. Most of these are one usage in many published versions of Apache HBase.
> 
> - 339 usages of Unsafe.loadFence, 1057 usages of Unsafe.storeFence, 517 usages of Unsafe.fullFence. A handful of these are libraries with copies of j.u.concurrent, the rest seem to be high performance libraries that support older JDK releases or just haven't been updated to use VarHandles yet.

Currently, all deprecated methods of `Unsafe` are at the end of the file. Is there a specific reason for this other than that they are deprecated? Would it make sense to move down the newly deprecated methods to the end of the file?

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

PR Comment: https://git.openjdk.org/jdk/pull/15641#issuecomment-1713249729

From jpai at openjdk.org  Mon Sep 11 06:49:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 11 Sep 2023 06:49:37 GMT
Subject: RFR: 8315973: Remove unused fields from ThreadLocalRandom
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Aug 2023 15:07:45 GMT, Andrey Turbanov  wrote:

> These messages were used before [JDK-8248862](https://bugs.openjdk.org/browse/JDK-8248862)

Looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15363#pullrequestreview-1619236418

From alanb at openjdk.org  Mon Sep 11 06:52:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Sep 2023 06:52:37 GMT
Subject: RFR: 8315938: Deprecate for removal Unsafe methods that have
 standard APIs for many releases
In-Reply-To: 
References: 
 
Message-ID: <_DvXTwT5ouEuQGb6eSyJespyu1uT2EKAjeJuNG9iCI0=.949b060b-60da-4f8d-94b9-be444b762c77@github.com>

On Mon, 11 Sep 2023 06:31:33 GMT, Per Minborg  wrote:

> Currently, all deprecated methods of `Unsafe` are at the end of the file.

Are you looking at the internal Unsafe, rather than sun.misc.Unsafe? This PR is sun.misc.Unsafe only. Previous deprecation didn't re-order the methods. With VarHandles in 9, and FFM highly likely to become permanent in 22, then we'll probably see a lot more deprecation, degrading and removing of methods. It would be noisy to reshuffle at every step.

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

PR Comment: https://git.openjdk.org/jdk/pull/15641#issuecomment-1713271383

From duke at openjdk.org  Mon Sep 11 07:13:07 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 07:13:07 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: 
References: 
Message-ID: <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>

> https://bugs.openjdk.org/browse/JDK-8310929
> 
> @TheRealMDoerr Feedback:
> 
> 
> We're getting test failures on AIX:
> compiler/intrinsics/Test8215792.java
> compiler/intrinsics/string/TestStringIntrinsics.java
> runtime/CompactStrings/TestMethodNames.java
> runtime/StringIntrinsic/StringIndexOfChar.java
> Is there a problem with Big Endian?

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

  remove ByteArrayLittleEndian

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15652/files
  - new: https://git.openjdk.org/jdk/pull/15652/files/911bbce8..e1e925b8

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

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

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

From dholmes at openjdk.org  Mon Sep 11 07:15:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Sep 2023 07:15:45 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: 
References: 
Message-ID: <-l07QgwUIOOMsXw9SniuLk856xxeIs8v6lwe8SWO_oI=.7c375b23-9f35-4d0d-a7bb-5fe513edb1d5@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson  wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Looks good. I have often pointed out that the CPE was not relevant for test files but ...

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1619274864

From simone.bordet at gmail.com  Mon Sep 11 07:29:34 2023
From: simone.bordet at gmail.com (Simone Bordet)
Date: Mon, 11 Sep 2023 09:29:34 +0200
Subject: Java 21 clinit deadlock
In-Reply-To: <77f901c7-5bb8-4703-8c64-b331913516b6@oracle.com>
References: 
 <77f901c7-5bb8-4703-8c64-b331913516b6@oracle.com>
Message-ID: 

Hi,

On Mon, Sep 11, 2023 at 7:22?AM David Holmes  wrote:
> I've looked at the dump and there is no sign that the MutableHttpFields
> is actively in use. It suggests to me that class initialization has
> failed but the class state has not been correctly updated and the
> waiters released. There were some changes in JDK 21 about how failures
> in this area were handled, so it is possible I/we got something wrong.
> Is it possible to try running this with additional logging enabled e.g.
>
> -Xlog:class+init=debug -Xlog:exceptions=debug

We will try this, than you!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From mdoerr at openjdk.org  Mon Sep 11 08:49:41 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 11 Sep 2023 08:49:41 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
References: 
 <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
Message-ID: 

On Mon, 11 Sep 2023 07:13:07 GMT, ???  wrote:

>> https://bugs.openjdk.org/browse/JDK-8310929
>> 
>> @TheRealMDoerr Feedback:
>> 
>> 
>> We're getting test failures on AIX:
>> compiler/intrinsics/Test8215792.java
>> compiler/intrinsics/string/TestStringIntrinsics.java
>> runtime/CompactStrings/TestMethodNames.java
>> runtime/StringIntrinsic/StringIndexOfChar.java
>> Is there a problem with Big Endian?
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ByteArrayLittleEndian

This helps. I'll run more tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1713446143

From aturbanov at openjdk.org  Mon Sep 11 08:51:42 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 11 Sep 2023 08:51:42 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 11 Sep 2023 04:00:34 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove duplicate stringSize
>  - update related comments

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 201:

> 199:      * @return index of the most significant digit or minus sign, if present
> 200:      */
> 201:     public static int getChars(int i, int index, byte[] buf) {

It's unused now. Do we expect usages to be added in following PRs?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321206741

From shade at openjdk.org  Mon Sep 11 08:58:41 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 11 Sep 2023 08:58:41 GMT
Subject: RFR: 8315942: Sort platform enums and definitions after
 JDK-8304913 follow-ups
In-Reply-To: 
References: 
Message-ID: 

On Fri, 8 Sep 2023 15:31:02 GMT, Aleksey Shipilev  wrote:

> @RogerRiggs asked for this. The moves are mechanical, so nothing should be lost. Tell me if other things need to be sorted as well.
> 
> I would wait a little to see if there are any more JDK-8304913 followups.

Any other reviews needed, or can I integrate?

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

PR Comment: https://git.openjdk.org/jdk/pull/15640#issuecomment-1713460299

From redestad at openjdk.org  Mon Sep 11 09:41:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Sep 2023 09:41:41 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 11 Sep 2023 08:49:18 GMT, Andrey Turbanov  wrote:

>> ??? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove duplicate stringSize
>>  - update related comments
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 201:
> 
>> 199:      * @return index of the most significant digit or minus sign, if present
>> 200:      */
>> 201:     public static int getChars(int i, int index, byte[] buf) {
> 
> It's unused now. Do we expect usages to be added in following PRs?

These weren't in `java.util.DecimalDigits` but have been copied from `java.lang.StringLatin1` - part of an unfinished refactoring? There's no clear-cut answer where these best fits but it seems reasonable to keep them in `StringLatin1` and `StringUTF16` respectively.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321272245

From duke at openjdk.org  Mon Sep 11 10:11:44 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 10:11:44 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
Message-ID: 

On Fri, 8 Sep 2023 20:36:31 GMT, ???  wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.toString"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lo | hi => hi | lo

@TheRealMDoerr Can you help me test this PR on AIX (big endian) ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1713581488

From duke at openjdk.org  Mon Sep 11 10:35:43 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 10:35:43 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v6]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 11 Sep 2023 09:38:44 GMT, Claes Redestad  wrote:

>> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 201:
>> 
>>> 199:      * @return index of the most significant digit or minus sign, if present
>>> 200:      */
>>> 201:     public static int getChars(int i, int index, byte[] buf) {
>> 
>> It's unused now. Do we expect usages to be added in following PRs?
>
> These weren't in `java.util.DecimalDigits` but have been copied from `java.lang.StringLatin1` - part of an unfinished refactoring? There's no clear-cut answer where these best fits but it seems reasonable to keep them in `StringLatin1` and `StringUTF16` respectively.

> It's unused now. Do we expect usages to be added in following PRs?

I plan to provide the getChars method in this PR and use it in my other PR #15555. I also plan to submit another PR to optimize java.time toString, and I will also use this method. https://github.com/wenshao/jdk/commit/cc82e8c11aeb27c0f8581363f7133c85f6022ca1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321338873

From ihse at openjdk.org  Mon Sep 11 10:37:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Sep 2023 10:37:45 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: 
References: 
Message-ID: 

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson  wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Looks good to me. Thanks for doing this cleanup!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1619669362

From mdoerr at openjdk.org  Mon Sep 11 11:03:40 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 11 Sep 2023 11:03:40 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
References: 
 <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
Message-ID: 

On Mon, 11 Sep 2023 07:13:07 GMT, ???  wrote:

>> https://bugs.openjdk.org/browse/JDK-8310929
>> 
>> @TheRealMDoerr Feedback:
>> 
>> 
>> We're getting test failures on AIX:
>> compiler/intrinsics/Test8215792.java
>> compiler/intrinsics/string/TestStringIntrinsics.java
>> runtime/CompactStrings/TestMethodNames.java
>> runtime/StringIntrinsic/StringIndexOfChar.java
>> Is there a problem with Big Endian?
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ByteArrayLittleEndian

This looks reasonable. The tests have passed on linux Big Endian and AIX. Thanks for fixing it so quickly. (Otherwise, backout and re-do would have been a good option as well.)

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15652#pullrequestreview-1619715473

From duke at openjdk.org  Mon Sep 11 11:32:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 11:32:41 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: 
References: 
 <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
 
Message-ID: 

On Mon, 11 Sep 2023 08:47:03 GMT, Martin Doerr  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove ByteArrayLittleEndian
>
> This helps. I'll run more tests.

@TheRealMDoerr 
Can you also help test the version Webrevs  00: [Full](https://webrevs.openjdk.org/?repo=jdk&pr=15652&range=00) ([911bbce8](https://git.openjdk.org/jdk/pull/15652/files/911bbce86d394ec8366a056c3eb5cb735286ff31)) ?

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1713694119

From jpai at openjdk.org  Mon Sep 11 11:59:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 11 Sep 2023 11:59:39 GMT
Subject: RFR: 8315942: Sort platform enums and definitions after
 JDK-8304913 follow-ups
In-Reply-To: 
References: 
Message-ID: 

On Fri, 8 Sep 2023 15:31:02 GMT, Aleksey Shipilev  wrote:

> @RogerRiggs asked for this. The moves are mechanical, so nothing should be lost. Tell me if other things need to be sorted as well.
> 
> I would wait a little to see if there are any more JDK-8304913 followups.

This looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15640#pullrequestreview-1619818810

From shade at openjdk.org  Mon Sep 11 12:08:39 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 11 Sep 2023 12:08:39 GMT
Subject: RFR: 8315942: Sort platform enums and definitions after
 JDK-8304913 follow-ups
In-Reply-To: 
References: 
Message-ID: 

On Fri, 8 Sep 2023 15:31:02 GMT, Aleksey Shipilev  wrote:

> @RogerRiggs asked for this. The moves are mechanical, so nothing should be lost. Tell me if other things need to be sorted as well.
> 
> I would wait a little to see if there are any more JDK-8304913 followups.

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/15640#issuecomment-1713745364

From shade at openjdk.org  Mon Sep 11 12:11:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 11 Sep 2023 12:11:49 GMT
Subject: Integrated: 8315942: Sort platform enums and definitions after
 JDK-8304913 follow-ups
In-Reply-To: 
References: 
Message-ID: 

On Fri, 8 Sep 2023 15:31:02 GMT, Aleksey Shipilev  wrote:

> @RogerRiggs asked for this. The moves are mechanical, so nothing should be lost. Tell me if other things need to be sorted as well.
> 
> I would wait a little to see if there are any more JDK-8304913 followups.

This pull request has now been integrated.

Changeset: 1941290b
Author:    Aleksey Shipilev 
URL:       https://git.openjdk.org/jdk/commit/1941290b7954033d76527f802bc4c343e8d9f2a8
Stats:     29 lines in 3 files changed: 12 ins; 11 del; 6 mod

8315942: Sort platform enums and definitions after JDK-8304913 follow-ups

Reviewed-by: rriggs, jpai

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

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

From duke at openjdk.org  Mon Sep 11 12:18:57 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 12:18:57 GMT
Subject: RFR: 8315999: Improve Date toString performance
Message-ID: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>

improve date toString performance, includes:

java.util.Date.toString
java.util.Date.toGMTString
java.time.Instant.toString
java.time.LocalDate.toString
java.time.LocalDateTime.toString
java.time.LocalTime.toString

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

Commit messages:
 - improve date toString performance, includes:

Changes: https://git.openjdk.org/jdk/pull/15658/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315999
  Stats: 663 lines in 12 files changed: 574 ins; 7 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/15658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658

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

From duke at openjdk.org  Mon Sep 11 12:23:36 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 12:23:36 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v7]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/ebcecc34..b4fe2aa1

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

  Stats: 119 lines in 6 files changed: 0 ins; 111 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From duke at openjdk.org  Mon Sep 11 12:23:38 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 12:23:38 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v6]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <6hpcRUcyN77dLmHXAvGAC2UM4hUJNdeBvdnTPLH2SRQ=.44cf0e26-79ec-4b38-bf36-f9cebf388805@github.com>

On Mon, 11 Sep 2023 10:33:10 GMT, ???  wrote:

>> These weren't in `java.util.DecimalDigits` but have been copied from `java.lang.StringLatin1` - part of an unfinished refactoring? There's no clear-cut answer where these best fits but it seems reasonable to keep them in `StringLatin1` and `StringUTF16` respectively.
>
>> It's unused now. Do we expect usages to be added in following PRs?
> 
> I plan to provide the getChars method in this PR and use it in my other PR #15555. I also plan to submit another PR to optimize java.time toString, and I will also use this method. https://github.com/wenshao/jdk/commit/cc82e8c11aeb27c0f8581363f7133c85f6022ca1

> These weren't in `java.util.DecimalDigits` but have been copied from `java.lang.StringLatin1` - part of an unfinished refactoring? There's no clear-cut answer where these best fits but it seems reasonable to keep them in `StringLatin1` and `StringUTF16` respectively.

StringLatin1.getChars has been moved to DecimalDigits.getCharsLatin1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321461917

From duke at openjdk.org  Mon Sep 11 12:32:38 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 12:32:38 GMT
Subject: RFR: 8315999: Improve Date toString performance
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

On Mon, 11 Sep 2023 12:12:17 GMT, ???  wrote:

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

@liach can you help me to review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713782721

From duke at openjdk.org  Mon Sep 11 12:51:38 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 12:51:38 GMT
Subject: RFR: 8315999: Improve Date toString performance
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

On Mon, 11 Sep 2023 12:12:17 GMT, ???  wrote:

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

@cl4es can you help me to review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713812730

From mdoerr at openjdk.org  Mon Sep 11 12:53:41 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 11 Sep 2023 12:53:41 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
References: 
 <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
Message-ID: 

On Mon, 11 Sep 2023 07:13:07 GMT, ???  wrote:

>> https://bugs.openjdk.org/browse/JDK-8310929
>> 
>> @TheRealMDoerr Feedback:
>> 
>> 
>> We're getting test failures on AIX:
>> compiler/intrinsics/Test8215792.java
>> compiler/intrinsics/string/TestStringIntrinsics.java
>> runtime/CompactStrings/TestMethodNames.java
>> runtime/StringIntrinsic/StringIndexOfChar.java
>> Is there a problem with Big Endian?
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ByteArrayLittleEndian

Your earlier version didn't work. The one which I have successfully tested is after 2nd commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1713815405

From simonis at openjdk.org  Mon Sep 11 13:10:39 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 11 Sep 2023 13:10:39 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass
In-Reply-To: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
Message-ID: 

On Fri, 8 Sep 2023 16:57:14 GMT, Mandy Chung  wrote:

> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`.   The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use).   If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size.   This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench.

In general looks good. But once you on this, I suggest to add the following additional optimizations:
- `FrameBuffer.START_POS` is `2` but as far as I can see, currently only the 0th element is reserved for passing a "magic" object passed between the JVM and Java code. So this should be set to `1`.
- `MIN_BATCH_SIZE` should be defined as in terms of `FrameBuffer.START_POS` (i.e. `FrameBuffer.START_POS + 1`)
- `StackFrameTraverser.batchSize()` should be changed to **really** honor the `estimateDepth` of `StackWalker.getInstance(.., estimateDepth)` (currently it is always `SMALL_BATCH` == `8` even if the caller specifies a smaller number):

-                int initialBatchSize = Math.max(walker.estimateDepth(), SMALL_BATCH);
+                int initialBatchSize = Math.max(walker.estimateDepth() + FrameBuffer.START_POS, MIN_BATCH_SIZE);

- In `CallerClassFinder.initFrameBuffer()` you can then use `this.frameBuffer = new ClassFrameBuffer(walker, FrameBuffer.START_POS + 2)`.

With these changes you would:
- save one more frame for the `getCallerClass()` case 
- save more frames for any user supplied `estimateDepth` values smaller than `8`
- don't implicitly expose `FrameBuffer.START_POS` to user space. Currently the user supplied `estimateDepth` value will be implicitly subtracted by `FrameBuffer.START_POS`
- make all the internal size computations depend explicitly on `FrameBuffer.START_POS` for better maintainability.

src/java.base/share/classes/java/lang/StackStreamFactory.java line 758:

> 756:          * So start the initial batch size with the minimum size.
> 757:          * If it fetches the second batch, getCallerClass may be invoked via
> 758:          * core reflection, can increase the next batch size.

This sentence reads strange to me. Maybe "If it fetches the second batch, getCallerClass may be invoked via core reflection, *so the next batch size will be increased.*"?

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

Changes requested by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15642#pullrequestreview-1619856398
PR Review Comment: https://git.openjdk.org/jdk/pull/15642#discussion_r1321463264

From mdoerr at openjdk.org  Mon Sep 11 13:34:47 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 11 Sep 2023 13:34:47 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
Message-ID: 

On Fri, 8 Sep 2023 20:36:31 GMT, ???  wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.toString"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lo | hi => hi | lo

I have run a couple of tests on linux Big Endian. They have passed. So, it's probably correct. However, I can't tell if it's good to use `ByteArrayLittleEndian`. I don't really like such platform details in the Java classes. Is that necessary for better performance on x86?

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1713892208

From liach at openjdk.org  Mon Sep 11 13:45:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Sep 2023 13:45:40 GMT
Subject: RFR: 8315999: Improve Date toString performance
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

On Mon, 11 Sep 2023 12:12:17 GMT, ???  wrote:

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

I think you should make this a dependent of #15651, so you can change the base branch of pr to `openjdk:pr/15651` and you can base your work off that pull request too.

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713910800

From mdoerr at openjdk.org  Mon Sep 11 13:45:52 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 11 Sep 2023 13:45:52 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
References: 
 <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
Message-ID: <2ilr4O-HnYlAvUJrANWMbROv2pqDk7Z7P-q42-kUtH0=.1add4675-9288-443a-8052-22fb42d961ec@github.com>

On Mon, 11 Sep 2023 07:13:07 GMT, ???  wrote:

>> https://bugs.openjdk.org/browse/JDK-8310929
>> 
>> @TheRealMDoerr Feedback:
>> 
>> 
>> We're getting test failures on AIX:
>> compiler/intrinsics/Test8215792.java
>> compiler/intrinsics/string/TestStringIntrinsics.java
>> runtime/CompactStrings/TestMethodNames.java
>> runtime/StringIntrinsic/StringIndexOfChar.java
>> Is there a problem with Big Endian?
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ByteArrayLittleEndian

GHA Pre-submit test results look good. Tests on AIX as well. Let's ship it!

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1713901618

From duke at openjdk.org  Mon Sep 11 13:45:55 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 13:45:55 GMT
Subject: Integrated: 8315970: Big-endian issues after JDK-8310929
In-Reply-To: 
References: 
Message-ID: <70GisoYMP63P3aLaX_mY5EZlRreEb25QtGnorAnAriw=.a144f6ce-c54d-4c6a-a843-82d7d174c60f@github.com>

On Sun, 10 Sep 2023 16:39:30 GMT, ???  wrote:

> https://bugs.openjdk.org/browse/JDK-8310929
> 
> @TheRealMDoerr Feedback:
> 
> 
> We're getting test failures on AIX:
> compiler/intrinsics/Test8215792.java
> compiler/intrinsics/string/TestStringIntrinsics.java
> runtime/CompactStrings/TestMethodNames.java
> runtime/StringIntrinsic/StringIndexOfChar.java
> Is there a problem with Big Endian?

This pull request has now been integrated.

Changeset: 4cb4637b
Author:    shaojin.wensj 
Committer: Martin Doerr 
URL:       https://git.openjdk.org/jdk/commit/4cb4637b797d0347f524662cbb853494573da7b9
Stats:     31 lines in 1 file changed: 6 ins; 20 del; 5 mod

8315970: Big-endian issues after JDK-8310929

Reviewed-by: mdoerr

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

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

From redestad at openjdk.org  Mon Sep 11 13:45:54 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Sep 2023 13:45:54 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: 
References: 
 <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
 
Message-ID: <31SaqmWQHFioS_SNn5hPsrTkWQ4G0LJ8g1qI9fIXemc=.627bf686-03b7-4dad-9d21-95fac95bb3b5@github.com>

On Mon, 11 Sep 2023 12:50:43 GMT, Martin Doerr  wrote:

> Your earlier version didn't work. The one which I have successfully tested is after 2nd commit.

I think this looks OK.

This patch probably reverts performance numbers on little-endian on some measures to pre-JDK-8310929 levels. A follow-up could examine if we can recuperate, e.g. differentiate the logic on big-endian, e.g. something like:

        charPos -= 2;
        if (BIG_ENDIAN) {
            putPair(..);
        } else {
            int packed = (int) StringLatin1.PACKED_DIGITS[-i];
            int inflated = ((packed & 0xFF00) << 8) | (packed & 0xFF);
            ByteArrayLittleEndian.setInt(buf, charPos << 1, inflated);
        }

        
It might also work generally if we made `int inflated = ((packed & 0xFF) << (16 + HI_BYTE_SHIFT)) | ((packed & 0xFF00) << HI_BYTE_SHIFT)`, but I have no way to test that and the performance of `ByteArrayLittleEndian` might be poor on AIX.

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1713907279

From duke at openjdk.org  Mon Sep 11 13:48:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 13:48:42 GMT
Subject: RFR: 8315999: Improve Date toString performance
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: 

On Mon, 11 Sep 2023 13:42:30 GMT, Chen Liang  wrote:

> I think you should make this a dependent of #15651, so you can change the base branch of pr to `openjdk:pr/15651` and you can base your work off that pull request too.

After PR #15651 is merged, changes will be made based on the new API. Until then, you can help review other changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713918857

From mdoerr at openjdk.org  Mon Sep 11 13:55:54 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 11 Sep 2023 13:55:54 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
References: 
 <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
Message-ID: 

On Mon, 11 Sep 2023 07:13:07 GMT, ???  wrote:

>> https://bugs.openjdk.org/browse/JDK-8310929
>> 
>> @TheRealMDoerr Feedback:
>> 
>> 
>> We're getting test failures on AIX:
>> compiler/intrinsics/Test8215792.java
>> compiler/intrinsics/string/TestStringIntrinsics.java
>> runtime/CompactStrings/TestMethodNames.java
>> runtime/StringIntrinsic/StringIndexOfChar.java
>> Is there a problem with Big Endian?
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ByteArrayLittleEndian

Shouldn't this get optimized by the JIT compilers? Why is `ByteArrayLittleEndian` supposed to be faster?
Note that there are still several Big Endian platforms: AIX, s390x and old linux ppc64 (still kept alive)

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1713936543

From redestad at openjdk.org  Mon Sep 11 13:58:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Sep 2023 13:58:41 GMT
Subject: RFR: 8315999: Improve Date toString performance
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

On Mon, 11 Sep 2023 12:12:17 GMT, ???  wrote:

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

As @liach says this should be done on top of #15651. As it stands now a thorough reviews seems a bit premature.

Correct me if I'm wrong but the gains come from inlining code into the various `toString` methods to reduce need to go through `DateTimeFormatter`s - which allocate `StringBuilder` and might go through chains of `CompositePrinterParser` and such.. It seems that before inlining and duplicating logic - making the code overall more fragile and harder to maintain - that we ought to see if we can get close enough by optimizing `DateTimeFormatter` and the corresponding builders to produce types that may optimize better.

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

> 1353:     @Override
> 1354:     public String toString() {
> 1355:         return DateTimeFormatter.ISO_INSTANT.format(this);

Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here? 

Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications.

src/java.base/share/classes/java/time/LocalDate.java line 2181:

> 2179:         if (yearAbs < 1000) {
> 2180:             if (year < 0) {
> 2181:                 buf[off] = '-';

`buf[off++] = '-';`

src/java.base/share/classes/java/time/LocalDate.java line 2188:

> 2186:             ByteArrayLittleEndian.setInt(
> 2187:                     buf,
> 2188:                     year < 0 ? 1 : 0,

`off,`

src/java.base/share/classes/java/time/LocalDate.java line 2192:

> 2190:         } else {
> 2191:             if (year > 9999) {
> 2192:                 buf[off] = '+';

`buf[off++] = '+';`?

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

PR Review: https://git.openjdk.org/jdk/pull/15658#pullrequestreview-1620003157
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321554515
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321590202
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321591620
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321588790

From duke at openjdk.org  Mon Sep 11 14:01:47 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 14:01:47 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
Message-ID: 

On Sun, 10 Sep 2023 18:54:33 GMT, Roger Riggs  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   lo | hi => hi | lo
>
> Given the endian-ness issues with https://git.openjdk.org/jdk/pull/14699.
> I'll need to run a more complete set of tests first (before its sponsored).

@RogerRiggs Can it be merged now?

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1713945956

From duke at openjdk.org  Mon Sep 11 14:04:57 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 14:04:57 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
References: 
 <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
Message-ID: 

On Mon, 11 Sep 2023 07:13:07 GMT, ???  wrote:

>> https://bugs.openjdk.org/browse/JDK-8310929
>> 
>> @TheRealMDoerr Feedback:
>> 
>> 
>> We're getting test failures on AIX:
>> compiler/intrinsics/Test8215792.java
>> compiler/intrinsics/string/TestStringIntrinsics.java
>> runtime/CompactStrings/TestMethodNames.java
>> runtime/StringIntrinsic/StringIndexOfChar.java
>> Is there a problem with Big Endian?
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ByteArrayLittleEndian

It will be faster to use ByteArrayLittle or ByteArrayLittleEndian. ByteArrayLittleEndian has an Integer.reverseBytes operation under the bigendian endian platform.

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1713953086

From aefimov at openjdk.org  Mon Sep 11 14:08:45 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 11 Sep 2023 14:08:45 GMT
Subject: Integrated: 8277954: Replace use of monitors with explicit locks in
 the JDK LDAP provider implementation
In-Reply-To: 
References: 
Message-ID: 

On Thu, 31 Aug 2023 22:48:30 GMT, Aleksei Efimov  wrote:

> The change proposed in this PR improves the behavior of the JDK JNDI/LDAP provider when running in a virtual thread. Currently, when an LDAP operation is performed from a virtual thread context a pinned carrier thread is detected:
> 
>      Thread[#29,ForkJoinPool-1-worker-1,5,CarrierThreads]
>         java.naming/com.sun.jndi.ldap.Connection.read reply(Connection.java:444) <== monitors:1
>         java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:369) <== monitors:1
>         java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:196) <== monitors:1
>         java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2896) <== monitors:1
> 
> To fix that monitor usages are replaced with `j.u.c` locks. All synchronized blocks/methods have been replaced with locks even if it is only guarding memory access - the motivation behind such a decision was to avoid an analysis of scenarios where a mix of monitors and `j.u.c` locks is used.
> 
> There are three types of mechanical changes done in this PR:
> 
> 1. Classes with `synchronized` blocks or `synchronized` methods have been updated to include a new `ReentrantLock` field. These new fields are used to replace `synchronized` blocks/methods.
> 1. classes that use notify/wait on object monitor have been updated to use `ReentrantLock.Condition`s signal/await.
> 1. if one class `synchronized` on an instance of another class - the `ReentrantLock` added in item (1) was made a package-protected to give access to another class.
> 
> With the proposed changes pinned carrier threads are no longer detected during execution of LDAP operations. 
> 
> Testing: `jdk-tier1` to `jdk-tier3`, other `jndi/ldap` regression and JCK naming tests show no failures.

This pull request has now been integrated.

Changeset: 66b6a5a8
Author:    Aleksei Efimov 
URL:       https://git.openjdk.org/jdk/commit/66b6a5a84f13157c8b02cf64f86c064517cd4710
Stats:     970 lines in 11 files changed: 394 ins; 101 del; 475 mod

8277954: Replace use of monitors with explicit locks in the JDK LDAP provider implementation

Reviewed-by: dfuchs

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

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

From liach at openjdk.org  Mon Sep 11 14:10:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Sep 2023 14:10:42 GMT
Subject: RFR: 8315999: Improve Date toString performance
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 
Message-ID: 

On Mon, 11 Sep 2023 13:45:43 GMT, ???  wrote:

> After PR #15651 is merged, changes will be made based on the new API. Until then, you can help review other changes.

I mean, OpenJDK's GitHub bots has a special handling system that allows you to include code from #15651 in this PR:

1. Merge your local [reduce_duplicate](https://github.com/wenshao/jdk/tree/reduce_duplicate) branch into your optimization date to string branch
2. Edit PR title image
3. Change PR branch image

Then OpenJDK bot will automatically add that you have a prerequisite in the issue body, and after merging #15651, this PR will automatically target against master again.

The main advantage is that PR's "File changed" on GitHub and webrevs will not include changes from #15651, so we can save review time and you don't have to update this PR after #15651 is merged.

-------------------------------
OpenJDK?GitHub?????????????????
1??? #15651 ?[reduce_duplicate](https://github.com/wenshao/jdk/tree/reduce_duplicate)Git??????????[optim_for_date_to_string_2](https://github.com/wenshao/jdk/tree/optim_for_date_to_string_2)???????
2??Pull Request??????"Edit"?????????????
3?????????`pr/15651`

????OpenJDK??????????????????????????integrated??????????????master?

??????"Files changed"??????????????????review??????????????????????

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1713964226

From redestad at openjdk.org  Mon Sep 11 14:12:52 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Sep 2023 14:12:52 GMT
Subject: RFR: 8315970: Big-endian issues after JDK-8310929 [v2]
In-Reply-To: 
References: 
 <9b2nQrw0qFsNhN0tRTt9Szxdb8JVw-NlANsf9sp7QhM=.3b8ecfb2-16d8-4f69-92c1-81a12236bca6@github.com>
 
Message-ID: 

On Mon, 11 Sep 2023 13:53:19 GMT, Martin Doerr  wrote:

> Shouldn't this get optimized by the JIT compilers? Why is `ByteArrayLittleEndian` supposed to be faster? Note that there are still several Big Endian platforms: AIX, s390x and old linux ppc64 (still kept alive)

And none of these are covered by Oracle-internal or GHA testing, sadly.

It'd be interesting to see performance numbers for `putPair` vs `ByteArrayLittleEndian.setInt` in isolation on x86. I.e. before and after this PR. When I've tested a similar thing for #15591 I saw a slight win on a two-byte pair (that might be due improved inlining decisions) but regressions on 4-byte or larger writes.

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

PR Comment: https://git.openjdk.org/jdk/pull/15652#issuecomment-1713969279

From liach at openjdk.org  Mon Sep 11 14:22:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Sep 2023 14:22:47 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
Message-ID: 

On Mon, 11 Sep 2023 13:32:07 GMT, Martin Doerr  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   lo | hi => hi | lo
>
> I have run a couple of tests on linux Big Endian. They have passed. So, it's probably correct. However, I can't tell if it's good to use `ByteArrayLittleEndian`. I don't really like such platform details in the Java classes. Is that necessary for better performance on x86?

@TheRealMDoerr `ByteArrayLittleEndian` only means that the input long/int/short/char will be seen as little-endian when written to a byte array; do you mean that assuming little-endian writes are faster is too platform-specific?

An alternative approach tried before is to pack the digits platform-specifically and use Unsafe (which bypasses platform-endianness reversals) to write directly; I recall it was rejected before, for using unsafe directly seems... unsafe :)

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1713988224

From mdoerr at openjdk.org  Mon Sep 11 14:27:50 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 11 Sep 2023 14:27:50 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
Message-ID: 

On Fri, 8 Sep 2023 20:36:31 GMT, ???  wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.toString"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lo | hi => hi | lo

I think making sure C2 optimizes it would be a better approach. Java classes shouldn't be optimized for performance on any endianness version IMHO. Rather for readability.
@offamitkumar, @deepa181, @JoKern65, @TOatGithub: You may want to check performance impact on s390x and AIX.

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1713996786

From liach at openjdk.org  Mon Sep 11 14:36:48 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Sep 2023 14:36:48 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 11 Sep 2023 12:23:36 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1

In short: I suggest splitting the change of moving `getChars` `stringSize` into another patch; they are sufficiently distinct and can shrink this PR's size by a half at least.

src/java.base/share/classes/java/lang/StringLatin1.java line 35:

> 33: import java.util.stream.Stream;
> 34: import java.util.stream.StreamSupport;
> 35: import jdk.internal.util.ArraysSupport;

Suggestion:

import jdk.internal.util.ArraysSupport;
import jdk.internal.util.DecimalDigits;

Assuming you will restore the `getChars` here.

src/java.base/share/classes/java/lang/StringLatin1.java line 42:

> 40: import static java.lang.String.checkIndex;
> 41: import static java.lang.String.checkOffset;
> 42: import static jdk.internal.util.DecimalDigits.digitPair;

Suggestion:


Redundant.

src/java.base/share/classes/java/lang/StringUTF16.java line 45:

> 43: 
> 44: import static jdk.internal.util.DecimalDigits.digitPair;
> 45: 

Suggestion:


Per previous comments.

Remember to add another line of 

import jdk.internal.util.DecimalDigits;

 above!

src/java.base/share/classes/java/lang/StringUTF16.java line 1549:

> 1547:             i = q;
> 1548: 
> 1549:             int packed = (int) digitPair(r);

Suggestion:

            int packed = (int) DecimalDigits.digitPair(r);

src/java.base/share/classes/java/lang/StringUTF16.java line 1558:

> 1556:         // We know there are at most two digits left at this point.
> 1557:         if (i < -9) {
> 1558:             int packed = (int) digitPair(-i);

Suggestion:

            int packed = (int) DecimalDigits.digitPair(-i);

src/java.base/share/classes/java/lang/StringUTF16.java line 1596:

> 1594:             q = i / 100;
> 1595: 
> 1596:             int packed = (int) digitPair((int)((q * 100) - i));

Suggestion:

            int packed = (int) DecimalDigits.digitPair((int)((q * 100) - i));

src/java.base/share/classes/java/lang/StringUTF16.java line 1610:

> 1608:             q2 = i2 / 100;
> 1609: 
> 1610:             int packed = (int) digitPair((q2 * 100) - i2);

Suggestion:

            int packed = (int) DecimalDigits.digitPair((q2 * 100) - i2);

src/java.base/share/classes/java/lang/StringUTF16.java line 1622:

> 1620:             charPos -= 2;
> 1621: 
> 1622:             int packed = (int) digitPair(-i2);

Suggestion:

            int packed = (int) DecimalDigits.digitPair(-i2);

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 43:

> 41:     }
> 42: 
> 43:     public int digits(long value, byte[] buffer, int index, MethodHandle putCharMH) throws Throwable {

`@Override`

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 143:

> 141:      * code after loop unrolling.
> 142:      */
> 143:     public static int stringSize(int x) {

I suggest splitting the moves of `stringSize` `getChars` into a new PR dependent on this one; your future date and time optimizations can depend on that one, which exposes stringSize.

Having the DecimalDigits package move and `stringSize` `getChars` moves together complicates the file changes, and it's hard to detect if there's any accidental typo/malicious code in the new additions.

src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 68:

> 66: 
> 67:     @Override
> 68:     public int digits(long value, byte[] buffer, int index, MethodHandle putCharMH) throws Throwable {

Can you revert these IDE reformatting changes? So that we don't pollute the changeset and the Git blame log, making reviews and reverting patches easier.

For example, only 3 lines of changes are truly necessary in this class:
Changing the package, `public ` before `final class OctalDigits` and `static final Digits INSTANCE`.

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

PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1619894567
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321648971
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321650127
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321646310
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321647751
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321647883
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321648031
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321648149
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321648317
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321487786
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321644436
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321640635

From amitkumar at openjdk.org  Mon Sep 11 14:41:46 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 11 Sep 2023 14:41:46 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v14]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
Message-ID: 

On Mon, 11 Sep 2023 14:24:31 GMT, Martin Doerr  wrote:

>@offamitkumar, @deepa181, @JoKern65, @TOatGithub: You may want to check performance impact on s390x and AIX.

@TheRealMDoerr Testing on s390 is not possible for now, as build is broken due to field resolution changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1714023981

From duke at openjdk.org  Mon Sep 11 14:44:24 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 14:44:24 GMT
Subject: RFR: 8315999: Improve Date toString performance [v2]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

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

  fix LocalDate.getChars offset

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/cc82e8c1..24adeb70

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

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

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

From duke at openjdk.org  Mon Sep 11 14:44:30 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 14:44:30 GMT
Subject: RFR: 8315999: Improve Date toString performance [v2]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: 

On Mon, 11 Sep 2023 13:50:30 GMT, Claes Redestad  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix LocalDate.getChars offset
>
> src/java.base/share/classes/java/time/LocalDate.java line 2181:
> 
>> 2179:         if (yearAbs < 1000) {
>> 2180:             if (year < 0) {
>> 2181:                 buf[off] = '-';
> 
> `buf[off++] = '-';`

this place doesn't need off++

> src/java.base/share/classes/java/time/LocalDate.java line 2192:
> 
>> 2190:         } else {
>> 2191:             if (year > 9999) {
>> 2192:                 buf[off] = '+';
> 
> `buf[off++] = '+';`?

this place doesn't need off++

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321658186
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321658742

From redestad at openjdk.org  Mon Sep 11 14:47:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Sep 2023 14:47:41 GMT
Subject: RFR: 8315999: Improve Date toString performance [v2]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 
Message-ID: 

On Mon, 11 Sep 2023 14:38:28 GMT, ???  wrote:

>> src/java.base/share/classes/java/time/LocalDate.java line 2181:
>> 
>>> 2179:         if (yearAbs < 1000) {
>>> 2180:             if (year < 0) {
>>> 2181:                 buf[off] = '-';
>> 
>> `buf[off++] = '-';`
>
> this place doesn't need off++

It was a suggestion, implicitly paired with removing ` + (year < 0 ? 1 : 0)` from line 2188.

>> src/java.base/share/classes/java/time/LocalDate.java line 2192:
>> 
>>> 2190:         } else {
>>> 2191:             if (year > 9999) {
>>> 2192:                 buf[off] = '+';
>> 
>> `buf[off++] = '+';`?
>
> this place doesn't need off++

Correct, though it's a bit opaque that `yearSize` includes room for the `'+'` that gets added on years > 9999 but that `jla.getChars` won't print that. This makes the logic somewhat fragile, which I think could be improved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321663810
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321666764

From duke at openjdk.org  Mon Sep 11 14:57:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 14:57:42 GMT
Subject: RFR: 8315999: Improve Date toString performance [v2]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com>

On Mon, 11 Sep 2023 13:29:14 GMT, Claes Redestad  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix LocalDate.getChars offset
>
> src/java.base/share/classes/java/time/Instant.java line 1355:
> 
>> 1353:     @Override
>> 1354:     public String toString() {
>> 1355:         return DateTimeFormatter.ISO_INSTANT.format(this);
> 
> Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here? 
> 
> Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications.

The performance of optimizing DateTimeFormatter cannot be as fast as using ixed-length buffer directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321680823

From duke at openjdk.org  Mon Sep 11 15:02:47 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 15:02:47 GMT
Subject: RFR: 8315999: Improve Date toString performance [v2]
In-Reply-To: <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com>
Message-ID: <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com>

On Mon, 11 Sep 2023 14:54:57 GMT, ???  wrote:

>> src/java.base/share/classes/java/time/Instant.java line 1355:
>> 
>>> 1353:     @Override
>>> 1354:     public String toString() {
>>> 1355:         return DateTimeFormatter.ISO_INSTANT.format(this);
>> 
>> Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here? 
>> 
>> Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications.
>
> The performance of optimizing DateTimeFormatter cannot be as fast as using ixed-length buffer directly.

Of course, the optimization of DateTimeFormatter is more general, and we can spend time doing it later. The format of toString is fixed, we can not use DateTimeFormatter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321686942

From jvernee at openjdk.org  Mon Sep 11 15:37:11 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 11 Sep 2023 15:37:11 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v20]
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 43 commits:

 - 8315917: Passing struct by values seems under specified
   
   Reviewed-by: mcimadamore
 - Merge branch 'master' into JEP22
 - Merge branch 'master' into JEP22
 - add code snippet
 - Split long throws clauses in `MemorySegment` javadoc
   
   Reviewed-by: jvernee
 - Add support for sliced allocation
 - add name of SysV ABI
 - Fix javadoc issues in MemorySegment::copy
   
   Reviewed-by: jvernee
 - remove reference to allocateArray
 - PPC linker changes
 - ... and 33 more: https://git.openjdk.org/jdk/compare/35bccacb...0e702f06

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

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=19
  Stats: 3759 lines in 244 files changed: 1901 ins; 1000 del; 858 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 duke at openjdk.org  Mon Sep 11 15:47:50 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 15:47:50 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v8]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  1. add override
  2. none static import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/b4fe2aa1..4a1eefae

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

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

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

From bpb at openjdk.org  Mon Sep 11 15:51:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 11 Sep 2023 15:51:43 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 8 Sep 2023 01:07:17 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: Handle "\\?\UNC"; add bad paths to test

> For input such as `\\\?\\foo` and `\\\?\\C:`, [...]
> 
> For `\\\?\\UNC` and `\\\?\\UNC\`, [...]

I will look into these cases.

The current patch passes all tier 1-3 tests in the CI pipeline.

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

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

From duke at openjdk.org  Mon Sep 11 15:52:21 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 15:52:21 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v9]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

 - fix merge conflict
 - Merge branch 'master' into reduce_duplicate
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/StringUTF16.java
 - 1. add override
   2. none static import
 - move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1
 - remove duplicate stringSize
 - update related comments
 - remove java.util.Digits
 - move java.util.Digits/HexDigits to jdk.internal.util.Digits/HexDigits
 - move java.util.OctalDigits to jdk.internal.util.OctalDigits
 - none static import
 - ... and 2 more: https://git.openjdk.org/jdk/compare/d06a5643...9b9eeb2d

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

Changes: https://git.openjdk.org/jdk/pull/15651/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=08
  Stats: 692 lines in 15 files changed: 313 ins; 352 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From duke at openjdk.org  Mon Sep 11 15:57:22 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 15:57:22 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v10]
In-Reply-To: 
References: 
Message-ID: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com>

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  revert code format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/9b9eeb2d..2b909d96

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

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

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

From duke at openjdk.org  Mon Sep 11 16:00:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 16:00:42 GMT
Subject: RFR: 8315999: Improve Date toString performance [v2]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: 

On Mon, 11 Sep 2023 14:44:24 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix LocalDate.getChars offset

# benchmark script

## 1. Script

bash configure
make images
sh make/devkit/createJMHBundle.sh
bash configure --with-jmh=build/jmh/jars
make test TEST="micro:java.time.ToStringBench.*


## 2. MacBookPro M1 Pro Benchmark 


``` diff
-Benchmark                                 Mode  Cnt    Score    Error   Units (baseline)
-ToStringBench.testInstantToString        thrpt   15    3.900 ?  0.289  ops/ms
-ToStringBench.testLocalDateTimeToString  thrpt   15   11.081 ?  0.141  ops/ms
-ToStringBench.testLocalDateToString      thrpt   15   18.566 ?  1.852  ops/ms
-ToStringBench.testLocalTimeToString      thrpt   15    8.428 ?  1.066  ops/ms
-ToStringBench.testZoneOffsetOffHours     thrpt   15  115.342 ? 13.978  ops/ms
-ToStringBench.testZonedDateTimeToString  thrpt   15    4.669 ?  1.986  ops/ms

+Benchmark                                 Mode  Cnt    Score   Error   Units (PR cc82e8c1)
+ToStringBench.testInstantToString        thrpt   15   47.971 ? 0.131  ops/ms (+1130.02%)
+ToStringBench.testLocalDateTimeToString  thrpt   15   71.310 ? 0.633  ops/ms (+543.53%)
+ToStringBench.testLocalDateToString      thrpt   15  108.236 ? 1.613  ops/ms (+482.97%)
+ToStringBench.testLocalTimeToString      thrpt   15  128.264 ? 1.052  ops/ms (+1421.87%)
+ToStringBench.testZoneOffsetOffHours     thrpt   15  694.463 ? 2.671  ops/ms (+502.29%)
+ToStringBench.testZonedDateTimeToString  thrpt   15   46.975 ? 0.850  ops/ms (+906.10%)

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1714168168

From duke at openjdk.org  Mon Sep 11 16:15:40 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 16:15:40 GMT
Subject: RFR: 8315999: Improve Date toString performance [v2]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 
 
Message-ID: 

On Mon, 11 Sep 2023 14:42:33 GMT, Claes Redestad  wrote:

>> this place doesn't need off++
>
> It was a suggestion, implicitly paired with removing ` + (year < 0 ? 1 : 0)` from line 2188.

The reason for not using off++ is that it can be executed out of order, which may result in better performance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1321781354

From bpb at openjdk.org  Mon Sep 11 16:27:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 11 Sep 2023 16:27:40 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 9 Sep 2023 08:32:44 GMT, Alan Bateman  wrote:

> For `\\\?\`, the normalization will drop the trailing slash so the path string is actually `\\\?`. I think that case is okay.

This results in "Bad pathname" with both the master and the change.

> For input such as `\\\?\\foo` and `\\\?\\C:`, the stripping results in a relative path, `foo` and `C:` in these examples, which means the canonicalize code is starting with a relative path. We have to be careful here as the path has always been make absolute before attempting to canonicalize.

These also fail with "Bad pathname" with the master but give the erroneous results `C:\\\foo` and `C:`, respectively, with the patch. This needs to be fixed.

> For `\\\?\\UNC` and `\\\?\\UNC\`, the stripping means these will be treated as `\`, which is the root directory of the current volume. I know these will fail with "The network path was not path" but I can't help thinking it should be rejected/throw early.

These actually fail with "Bad pathname" for both the master and the patch.

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

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

From duke at openjdk.org  Mon Sep 11 16:36:25 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 16:36:25 GMT
Subject: RFR: 8315999: Improve Date toString performance [v3]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

??? has updated the pull request with a new target base 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:

 - base PR #15651 API
 - Merge remote-tracking branch 'origin/reduce_duplicate' into optim_for_date_to_string_2
 - fix LocalDate.getChars offset
 - improve date toString performance, includes:
   
   java.util.Date.toString
   java.util.Date.toGMTString
   java.time.Instant.toString
   java.time.LocalDate.toString
   java.time.LocalDateTime.toString
   java.time.LocalTime.toString

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/24adeb70..ef500237

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

  Stats: 2901 lines in 74 files changed: 1701 ins; 585 del; 615 mod
  Patch: https://git.openjdk.org/jdk/pull/15658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658

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

From duke at openjdk.org  Mon Sep 11 16:40:44 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 16:40:44 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 11 Sep 2023 14:28:28 GMT, Chen Liang  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 143:
> 
>> 141:      * code after loop unrolling.
>> 142:      */
>> 143:     public static int stringSize(int x) {
> 
> I suggest splitting the moves of `stringSize` `getChars` into a new PR dependent on this one; your future date and time optimizations can depend on that one, which exposes stringSize.
> 
> Having the DecimalDigits package move and `stringSize` `getChars` moves together complicates the file changes, and it's hard to detect if there's any accidental typo/malicious code in the new additions.

If this PR is split into two PRs, the other two PRs I submitted #15658 #15555 cannot be based on this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321809367

From naoto at openjdk.org  Mon Sep 11 16:52:02 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Sep 2023 16:52:02 GMT
Subject: Integrated: 8041488: Locale-Dependent List Patterns
In-Reply-To: 
References: 
Message-ID: 

On Wed, 2 Aug 2023 23:22:56 GMT, Naoto Sato  wrote:

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

This pull request has now been integrated.

Changeset: d0be73a7
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/d0be73a78038faf9509623bc4ba71eb4385cd645
Stats:     1019 lines in 7 files changed: 1011 ins; 0 del; 8 mod

8041488: Locale-Dependent List Patterns

Reviewed-by: joehw, rriggs

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

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

From dl at openjdk.org  Mon Sep 11 16:54:30 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 11 Sep 2023 16:54:30 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v29]
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:

  Force more orderings; improve diagnostics

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/31a1f34e..4eeb5e5a

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

  Stats: 55 lines in 2 files changed: 13 ins; 18 del; 24 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  Mon Sep 11 16:59:42 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 11 Sep 2023 16:59:42 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v29]
In-Reply-To: 
References: 
 
Message-ID: <6E7JVuf0BKaOXE7mZ15tosm48KSMFkvdTb1ZQAvE9Xg=.ce4ddb8a-61eb-4008-8861-598eee0013e8@github.com>

On Mon, 11 Sep 2023 16:54:30 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:
> 
>   Force more orderings; improve diagnostics

src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 910:

> 908:             else
> 909:                 throw new IllegalStateException("Task was cancelled");
> 910:         }

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1321831386

From mchung at openjdk.org  Mon Sep 11 17:27:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Sep 2023 17:27:15 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v2]
In-Reply-To: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
Message-ID: <21pWkHjDdGAm0uQt54H5kE9FCAco70QnPc3vHs8FQNY=.6d7be466-c9ce-4527-af4c-2eff22c94d4f@github.com>

> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`.   The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use).   If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size.   This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15642/files
  - new: https://git.openjdk.org/jdk/pull/15642/files/86b3fbf2..c971d220

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

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

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

From mchung at openjdk.org  Mon Sep 11 17:34:40 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Sep 2023 17:34:40 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v2]
In-Reply-To: <21pWkHjDdGAm0uQt54H5kE9FCAco70QnPc3vHs8FQNY=.6d7be466-c9ce-4527-af4c-2eff22c94d4f@github.com>
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
 <21pWkHjDdGAm0uQt54H5kE9FCAco70QnPc3vHs8FQNY=.6d7be466-c9ce-4527-af4c-2eff22c94d4f@github.com>
Message-ID: 

On Mon, 11 Sep 2023 17:27:15 GMT, Mandy Chung  wrote:

>> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`.   The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use).   If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size.   This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

> In general looks good. But once you on this, I suggest to add the following additional optimizations:
> 
> * `FrameBuffer.START_POS` is `2` but as far as I can see, currently only the 0th element is reserved for passing a "magic" object passed between the JVM and Java code. So this should be set to `1`.
>    ....
> 
> With these changes you would:
> 
>  * save one more frame for the `getCallerClass()` case

Note that this only affects the number of elements allocated.   `getCallerClass` only walks 2 frames in the first batch regardless of the number of reserved elements.


Benchmark                        Mode  Cnt  Score   Error  Units
CallerClassBench.getCallerClass  avgt   15  0.361 ? 0.003  us/op   // num of reserved elements = 1
CallerClassBench.getCallerClass  avgt   15  0.370 ? 0.009  us/op  // num of reserved elements = 2

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

PR Comment: https://git.openjdk.org/jdk/pull/15642#issuecomment-1714303844

From mchung at openjdk.org  Mon Sep 11 17:34:42 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Sep 2023 17:34:42 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v2]
In-Reply-To: 
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
 
Message-ID: 

On Mon, 11 Sep 2023 12:18:42 GMT, Volker Simonis  wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> src/java.base/share/classes/java/lang/StackStreamFactory.java line 758:
> 
>> 756:          * So start the initial batch size with the minimum size.
>> 757:          * If it fetches the second batch, getCallerClass may be invoked via
>> 758:          * core reflection, can increase the next batch size.
> 
> This sentence reads strange to me. Maybe "If it fetches the second batch, getCallerClass may be invoked via core reflection, *so the next batch size will be increased.*"?

I updated and moved the comment to `batchSize` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15642#discussion_r1321863905

From mchung at openjdk.org  Mon Sep 11 17:50:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Sep 2023 17:50:09 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v3]
In-Reply-To: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
Message-ID: 

> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`.   The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use).   If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size.   This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Make number of the reserved elements to 1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15642/files
  - new: https://git.openjdk.org/jdk/pull/15642/files/c971d220..3df1ca13

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

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

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

From mchung at openjdk.org  Mon Sep 11 17:52:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Sep 2023 17:52:56 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v4]
In-Reply-To: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
Message-ID: <4tTHtnDKfaPHhUpYVq4RO-3SS2PcNrCPDSwillvAyA8=.323fed3c-5115-470d-989a-cbbdc99027c9@github.com>

> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`.   The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use).   If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size.   This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15642/files
  - new: https://git.openjdk.org/jdk/pull/15642/files/3df1ca13..b250597b

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

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

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

From prappo at openjdk.org  Mon Sep 11 18:05:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 11 Sep 2023 18:05:55 GMT
Subject: RFR: 8316038: Fix doc typos in java.io.Console and java.util.Scanner
Message-ID: 

Please review this trivial PR.

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

Commit messages:
 - Initial commit

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

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

From bpb at openjdk.org  Mon Sep 11 18:10:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 11 Sep 2023 18:10:40 GMT
Subject: RFR: 8316038: Fix doc typos in java.io.Console and
 java.util.Scanner
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 17:58:20 GMT, Pavel Rappo  wrote:

> Please review this trivial PR.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15667#pullrequestreview-1620550935

From jbhateja at openjdk.org  Mon Sep 11 18:28:57 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 11 Sep 2023 18:28:57 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v34]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 8 Sep 2023 18:10:33 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:
> 
>   Fix regression when intrinsics are disabled; enable insertion sort in intrinsic, change library name to libsimdsort

Overall patch looks good to me, apart from a minor refactoring suggestion.

> > > 
> > 
> > 
> > Hi @vamsi-parasa ,
> > Please find below the perf data collected over ?Linux? with following JMH options. Idea here is to measure the impact of Java side code re-structuring over non-x86 targets and windows machines which do not intrinsify newly created primitives.
> > java -jar target/benchmarks.jar -p builder=RANDOM -f 1 -wi 1 -i 10 -w 30 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySort,_arrayPartition" ArraysSort.Long.testSort
> > Baseline numbers are with stock JDK.
> > ![image](https://user-images.githubusercontent.com/59989778/264077119-d3bf2591-38bb-4924-b77d-6889c5dbc3c0.png)
> > It will also be good to mention in PR description as to why are not accelerating sorting for short/char arrays when x86-simd-sort does have avx512 optimized versions for 16-bit arrays sorting.
> > Best Regards, Jatin
> 
> Hello Jatin,
> 
> In the table below, please see the performance data (on Linux x86 machine) when the intrinsics are disabled w.r.t to the stock JDK as baseline. The regression is fixed in the latest commit pushed.
> 
> This data was collected using the same way as yours: `java -jar target/benchmarks.jar -p builder=RANDOM -f 1 -wi 1 -i 10 -w 30 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySortI,_arraySortMI,_arrayPartitionSP,_arrayPartitionDP" ArraysSort.Long.testSort`
> 
> Please note the new names of the intrinsics.
> 
> Benchmark	(builder)	(size)	Baseline (Stock JDK) us/op	RSD (baseline)	AVX512 sort (intrinsics disabled) us/op	RSD (AVX512 sort)	Speedup
> ArraysSort.Long.testSort	RANDOM	800	6.4	0.1%	6.3	0.43%	1.02
> ArraysSort.Long.testSort	RANDOM	7000	210.2	0.5%	205.5	0.24%	1.02
> ArraysSort.Long.testSort	RANDOM	50000	2087.2	0.1%	2057.5	0.18%	1.01
> ArraysSort.Long.testSort	RANDOM	300000	14076.0	0.3%	14245.2	0.13%	0.99
> ArraysSort.Long.testSort	RANDOM	2000000	111576.6	0.4%	110024.9	0.04%	1.01
> Thanks, Vamsi

Thanks @vamsi-parasa  for addressing this.

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

> 4203: 
> 4204:       snprintf(ebuf_, sizeof(ebuf_), "avx512_sort_double");
> 4205:       StubRoutines::_arraysort_double = (address)os::dll_lookup(libsimdsort, ebuf_);

Hi @vamsi-parasa , If we align these C++ stub entry points with java intrinsic entry points which accept an element class argument, it will significantly cleanup the code referring to these stub entry points. We can pass an extra int type flag to stubs based on which C++ implementation can appropriately call type specific leaf level routines.

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

PR Review: https://git.openjdk.org/jdk/pull/14227#pullrequestreview-1620565021
PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1714374347
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1321907992

From roger.riggs at oracle.com  Mon Sep 11 18:38:54 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 11 Sep 2023 14:38:54 -0400
Subject: Result: New Core Libraries Group Member: Daniel Fuchs
Message-ID: <527628c7-948e-f655-de6b-cdb6387c98c6@oracle.com>

The vote for Daniel Fuchs [1] is now closed.

Yes: 10
Veto: 0
Abstain: 0

|According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. Roger Riggs [1] 
https://mail.openjdk.org/pipermail/core-libs-dev/2023-August/110852.html |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From roger.riggs at oracle.com  Mon Sep 11 18:39:04 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 11 Sep 2023 14:39:04 -0400
Subject: Result: New Core Libraries Group Member: Michael McMahon
Message-ID: 

The vote for Michael McMahon [1] is now closed.

Yes:? 10
Veto: 0
Abstain: 0

|According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. Roger Riggs [1] 
https://mail.openjdk.org/pipermail/core-libs-dev/2023-August/110854.html |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From roger.riggs at oracle.com  Mon Sep 11 18:39:11 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 11 Sep 2023 14:39:11 -0400
Subject: Result: New Core Libraries Group Member: Lance Andersen
Message-ID: <8b94a37f-d870-0f94-a1e9-10cf697c7ab5@oracle.com>

The vote for Lance Andersen [1] is now closed.

Yes: 10
Veto: 0
Abstain: 0

|According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. Roger Riggs [1] 
https://mail.openjdk.org/pipermail/core-libs-dev/2023-August/110853.html |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From redestad at openjdk.org  Mon Sep 11 18:59:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Sep 2023 18:59:46 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v10]
In-Reply-To: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com>
References: 
 <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com>
Message-ID: 

On Mon, 11 Sep 2023 15:57:22 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert code format

src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 37:

> 35:  * @since 21
> 36:  */
> 37: public final class OctalDigits implements Digits {

Can you restore the order of methods here to minimize the number of lines of code are touched?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321956051

From rriggs at openjdk.org  Mon Sep 11 19:03:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Sep 2023 19:03:42 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v10]
In-Reply-To: <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com>
References: 
 <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com>
Message-ID: 

On Mon, 11 Sep 2023 15:57:22 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert code format

Changes requested by rriggs (Reviewer).

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 1:

> 1: /*

Can git be convinced to show this as a rename instead of a delete and add?
The history will be cleaner.

src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 41:

> 39:      * Singleton instance of OctalDigits.
> 40:      */
> 41:     public static final Digits INSTANCE = new OctalDigits();

The constructor should be after the field definitions. 
Don't let some tool reformat the code and move things around.

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

PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1620644060
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321958613
PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321960820

From rriggs at openjdk.org  Mon Sep 11 19:03:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Sep 2023 19:03:44 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v7]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 11 Sep 2023 16:36:55 GMT, ???  wrote:

>> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 143:
>> 
>>> 141:      * code after loop unrolling.
>>> 142:      */
>>> 143:     public static int stringSize(int x) {
>> 
>> I suggest splitting the moves of `stringSize` `getChars` into a new PR dependent on this one; your future date and time optimizations can depend on that one, which exposes stringSize.
>> 
>> Having the DecimalDigits package move and `stringSize` `getChars` moves together complicates the file changes, and it's hard to detect if there's any accidental typo/malicious code in the new additions.
>
> If this PR is split into two PRs, the other two PRs I submitted #15658 #15555 cannot be based on this PR.

I agree, do the package move separate from the refactoring. 
The other PRs can wait a bit or be committed as is and take part in the refactoring later. 
One step at a time please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321957533

From redestad at openjdk.org  Mon Sep 11 19:06:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 11 Sep 2023 19:06:42 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v10]
In-Reply-To: 
References: 
 <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com>
 
Message-ID: <_-7S7GhHC7J1aoj_lSPIULTtjhr2RdHsssbMnbHe4Wo=.0ffc1dc5-abee-42c9-a1cd-71b5637ed72a@github.com>

On Mon, 11 Sep 2023 18:58:56 GMT, Roger Riggs  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert code format
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 1:
> 
>> 1: /*
> 
> Can git be convinced to show this as a rename instead of a delete and add?
> The history will be cleaner.

I just looked it up and git actually doesn't have commands for renames like hg, but rather decides if something is a delete+add or a rename based on the amount of changes. Too many changes and it'll automatically look like a remove+add. 

Which is yet another argument for splitting up this in multiple PRs. One to move, one to refactor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1321963536

From naoto at openjdk.org  Mon Sep 11 19:35:39 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Sep 2023 19:35:39 GMT
Subject: RFR: 8316038: Fix doc typos in java.io.Console and
 java.util.Scanner
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 17:58:20 GMT, Pavel Rappo  wrote:

> Please review this trivial PR.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15667#pullrequestreview-1620699998

From iris at openjdk.org  Mon Sep 11 19:57:37 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 11 Sep 2023 19:57:37 GMT
Subject: RFR: 8316038: Fix doc typos in java.io.Console and
 java.util.Scanner
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 17:58:20 GMT, Pavel Rappo  wrote:

> Please review this trivial PR.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15667#pullrequestreview-1620730522

From lbourges at openjdk.org  Mon Sep 11 20:37:53 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 11 Sep 2023 20:37:53 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v34]
In-Reply-To: 
References: 
 
Message-ID: <5zXR3l_RDiuqozvZ_GZwbD9OsSJUiTjYz4-EH8LxrOE=.35262f97-5bf0-4ca2-8e84-678c093bdb35@github.com>

On Fri, 8 Sep 2023 18:10:33 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:
> 
>   Fix regression when intrinsics are disabled; enable insertion sort in intrinsic, change library name to libsimdsort

Please do not give random distribution too much importance as it represents very-low probability case. Most datasets are correlated so pure random data is far from most representative datasets.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1714540984

From dl at openjdk.org  Mon Sep 11 20:49:34 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 11 Sep 2023 20:49:34 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v30]
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 75 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Force more orderings; improve diagnostics
 - Simplify signalling
 - Always help terminate when stopping
 - Merge branch 'openjdk:master' into JDK-8288899
 - Use non-recursive tasks in close tests
 - Allow ThreadGroup access in tck tests
 - Avoid needing test threads
 - Merge branch 'openjdk:master' into JDK-8288899
 - Avoid jtreg test group
 - ... and 65 more: https://git.openjdk.org/jdk/compare/def5d265...729e34f6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/4eeb5e5a..729e34f6

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

  Stats: 7615 lines in 177 files changed: 4876 ins; 1947 del; 792 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  Mon Sep 11 21:18:49 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 11 Sep 2023 21:18:49 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v20]
In-Reply-To: 
References: 
 
Message-ID: <6ekIcAU0bARYkB_E_QCPD4u9jnqtFgEXCpImDcaxVPE=.a2b116fe-409b-4867-a389-d53ad1a94873@github.com>

On Mon, 11 Sep 2023 15:37:11 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 with a new target base due to a merge or a rebase. The pull request now contains 43 commits:
> 
>  - 8315917: Passing struct by values seems under specified
>    
>    Reviewed-by: mcimadamore
>  - Merge branch 'master' into JEP22
>  - Merge branch 'master' into JEP22
>  - add code snippet
>  - Split long throws clauses in `MemorySegment` javadoc
>    
>    Reviewed-by: jvernee
>  - Add support for sliced allocation
>  - add name of SysV ABI
>  - Fix javadoc issues in MemorySegment::copy
>    
>    Reviewed-by: jvernee
>  - remove reference to allocateArray
>  - PPC linker changes
>  - ... and 33 more: https://git.openjdk.org/jdk/compare/35bccacb...0e702f06

src/java.base/share/classes/java/lang/foreign/Linker.java line 573:

> 571:      * The returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
> 572:      * representing the target address of the foreign function is the {@link MemorySegment#NULL} address. If an argument
> 573:      * is a {@link MemorySegment},whose corresponding layout is an {@linkplain GroupLayout group layout}, the linker might attempt to access the contents of the segment. As such, one of the exceptions specified by the

**Nit:**
Suggestion:

     * is a {@link MemorySegment},whose corresponding layout is a {@linkplain GroupLayout group layout}, the linker might attempt to access the contents of the segment. As such, one of the exceptions specified by the

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1322081045

From pminborg at openjdk.org  Mon Sep 11 21:24:50 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Sep 2023 21:24:50 GMT
Subject: RFR: 8316050: Use hexadecimal encoding in MemorySegment::toString
Message-ID: 

This PR proposes to use hexadecimal representation for a memory segment address rather than a decimal one.

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

Commit messages:
 - Use hexadecimal encoding in MemorySegment::toString

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

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

From rriggs at openjdk.org  Mon Sep 11 21:46:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Sep 2023 21:46:39 GMT
Subject: RFR: 8316050: Use hexadecimal encoding in MemorySegment::toString
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 21:17:27 GMT, Per Minborg  wrote:

> This PR proposes to use hexadecimal representation for a memory segment address rather than a decimal one.

Seems more natural.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15670#pullrequestreview-1620876854

From duke at openjdk.org  Mon Sep 11 21:54:51 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 11 Sep 2023 21:54:51 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v33]
In-Reply-To: 
References: 
 
 
Message-ID: <91FjgVViyJDrSvMr-DrrcjempfIPEYQApt-jYH7651Y=.10e42ce4-9534-4f3d-90a8-4b32bcf65602@github.com>

On Fri, 8 Sep 2023 05:33:49 GMT, Alan Bateman  wrote:

> Would it be possible to provide a clear summary on why libx86_64_sort is being added? I'm trying to understand why these weren't linked into libjvm.

Hello Alan,

Initially, the reason behind adding libx86_64 (now renamed to libsimdsort in the latest commit) as a shared library was the unavailability of AVX512 instructions on all x86 CPUs. This approach enables the stubs to be loaded only for the platforms that support AVX512 and skipped for others. 

We are open to suggestions and make any necessary changes as needed. Please let us know.

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1714634691

From bpb at openjdk.org  Mon Sep 11 22:31:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 11 Sep 2023 22:31:15 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 22:22:47 GMT, Brian Burkhalter  wrote:

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

Unfortunately, reformatting caused there to appear to be a lot of changes in the `SetAccess` test when the principal change to the test is the first section of `doTest` for a non-existent file.

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

PR Comment: https://git.openjdk.org/jdk/pull/15673#issuecomment-1714666326

From mcimadamore at openjdk.org  Mon Sep 11 22:31:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Sep 2023 22:31:42 GMT
Subject: RFR: 8316050: Use hexadecimal encoding in MemorySegment::toString
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 21:17:27 GMT, Per Minborg  wrote:

> This PR proposes to use hexadecimal representation for a memory segment address rather than a decimal one.

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 508:

> 506:     @Override
> 507:     public String toString() {
> 508:         return "MemorySegment{ heapBase: " + heapBase() + " address: 0x" + Long.toHexString(address()) + " limit: " + length + " }";

should we replace `limit` with `size` since we're here? (the javadoc says segments have size, not limit)

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

PR Review: https://git.openjdk.org/jdk/pull/15670#pullrequestreview-1620936858
PR Review Comment: https://git.openjdk.org/jdk/pull/15670#discussion_r1322131311

From bpb at openjdk.org  Mon Sep 11 22:31:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 11 Sep 2023 22:31:15 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not exist
Message-ID: 

On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

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

Commit messages:
 - 8316000: File.setExecutable silently fails if file does not exist

Changes: https://git.openjdk.org/jdk/pull/15673/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316000
  Stats: 106 lines in 2 files changed: 59 ins; 35 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/15673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15673/head:pull/15673

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

From naoto at openjdk.org  Mon Sep 11 22:57:38 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Sep 2023 22:57:38 GMT
Subject: RFR: JDK-8315946: DecimalFormat and CompactNumberFormat do allow
 U+FFFE and U+FFFF in the pattern
In-Reply-To: 
References: 
Message-ID: 

On Fri, 8 Sep 2023 23:02:02 GMT, Justin Lu  wrote:

> Please review this change which adjusts the pattern syntax specification for the two classes to represent the actual behavior. That is, U+FFFE and U+FFFF are allowed in the suffix/prefix. (Additionally; 'Unicode' is dropped from the definitions, as a Java character is composed of Unicode code points).
> 
> See code below, no exception is thrown.
> 
> 
> String uFFFE = "\uFFFE";
> String uFFFF = "\uFFFF";
> var a = new DecimalFormat("prefixStart"+uFFFE+"0.00"+uFFFF+"SuffixEnd");
> a.format(1); // returns "prefixStart?1.00?SuffixEnd"
> var b = new CompactNumberFormat(a.toPattern(), a.getDecimalFormatSymbols(), new String[] {""});
> b.format(1); // returns "prefixStart?1?SuffixEnd"

LGTM. Reviewed the CSR too.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15648#pullrequestreview-1620956331

From duke at openjdk.org  Mon Sep 11 22:59:23 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 22:59:23 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v11]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

 - revert stringSize refactor
 - revert stringSize refactor
 - restore the order of OctalDigits methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/2b909d96..9bf9f787

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

  Stats: 212 lines in 8 files changed: 108 ins; 83 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From duke at openjdk.org  Mon Sep 11 23:05:08 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 23:05:08 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v12]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  DecimalDigits revert some changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/9bf9f787..196a3393

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

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

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

From duke at openjdk.org  Mon Sep 11 23:08:14 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 23:08:14 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v13]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  DecimalDigits revert some changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/196a3393..03952930

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

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

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

From duke at openjdk.org  Mon Sep 11 23:27:12 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 23:27:12 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v14]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  rebase & resolve DecimalDigits delete and add

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

Changes: https://git.openjdk.org/jdk/pull/15651/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=13
  Stats: 577 lines in 13 files changed: 274 ins; 279 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From duke at openjdk.org  Mon Sep 11 23:34:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 23:34:41 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v10]
In-Reply-To: <_-7S7GhHC7J1aoj_lSPIULTtjhr2RdHsssbMnbHe4Wo=.0ffc1dc5-abee-42c9-a1cd-71b5637ed72a@github.com>
References: 
 <1dRCC38aUB8YK08ign9lZvbqJgZiowewL48eKRUT9ro=.588614fb-ef2d-44ed-a066-80b43bb24b1e@github.com>
 
 <_-7S7GhHC7J1aoj_lSPIULTtjhr2RdHsssbMnbHe4Wo=.0ffc1dc5-abee-42c9-a1cd-71b5637ed72a@github.com>
Message-ID: 

On Mon, 11 Sep 2023 19:03:45 GMT, Claes Redestad  wrote:

>> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 1:
>> 
>>> 1: /*
>> 
>> Can git be convinced to show this as a rename instead of a delete and add?
>> The history will be cleaner.
>
> I just looked it up and git actually doesn't have commands for renames like hg, but rather decides if something is a delete+add or a rename based on the amount of changes. Too many changes and it'll automatically look like a remove+add. 
> 
> Which is yet another argument for splitting up this in multiple PRs. One to move, one to refactor.

Refactoring of stringSize has been restored, But the problem of 'delete & add' is still not solved, I tried rebase but it couldn't be solved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1322178111

From duke at openjdk.org  Mon Sep 11 23:34:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 23:34:42 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v7]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 11 Sep 2023 18:57:58 GMT, Roger Riggs  wrote:

>> If this PR is split into two PRs, the other two PRs I submitted #15658 #15555 cannot be based on this PR.
>
> I agree, do the package move separate from the refactoring. 
> The other PRs can wait a bit or be committed as is and take part in the refactoring later. 
> One step at a time please.

Refactoring of stringSize has been restored

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15651#discussion_r1322178873

From serb at openjdk.org  Mon Sep 11 23:45:38 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 11 Sep 2023 23:45:38 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation
In-Reply-To: 
References: 
Message-ID: 

On Sat, 9 Sep 2023 14:33:53 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

test/jdk/java/util/zip/ZipFile/MissingZIP64EntriesTest.java line 52:

> 50:  * starting number is set to 0xFFFF or when we have a valid Zip64 Extra header
> 51:  * size but missing the corresponding field.
> 52:  * @run junit MissingZIP64EntriesTest

Is this comment accurate? I think we should check 3 cases when the header extra len == 0, len == 8 and len ==16, but still do not contain all required information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15650#discussion_r1322185302

From duke at openjdk.org  Mon Sep 11 23:50:44 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 11 Sep 2023 23:50:44 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v15]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

??? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - use StringLatin1.PACKED_DIGITS and add getCharsLatin1
 - rebase & resolve DecimalDigits delete and add

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/6cc34bed..70bf2297

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

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

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

From duke at openjdk.org  Tue Sep 12 00:00:24 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 00:00:24 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v16]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

??? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  rebase & resolve DecimalDigits delete and add

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/70bf2297..9bccc890

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=14-15

  Stats: 282 lines in 7 files changed: 145 ins; 123 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From duke at openjdk.org  Tue Sep 12 00:06:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 00:06:41 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v17]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

??? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  rebase & resolve DecimalDigits delete and add

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/9bccc890..27174f45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=15-16

  Stats: 52 lines in 3 files changed: 11 ins; 35 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15651/head:pull/15651

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

From liach at openjdk.org  Tue Sep 12 00:52:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Sep 2023 00:52:52 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v17]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 12 Sep 2023 00:06:41 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   rebase & resolve DecimalDigits delete and add

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1621068014

From duke at openjdk.org  Tue Sep 12 01:00:39 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 01:00:39 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v18]
In-Reply-To: 
References: 
Message-ID: 

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  little-endian

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/27174f45..93ed81da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=16-17

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

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

From duke at openjdk.org  Tue Sep 12 01:23:26 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 01:23:26 GMT
Subject: RFR: 8315999: Improve Date toString performance [v4]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

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

 - rebase PR #15651 last version
 - base PR #15651 API
 - move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1
 - remove duplicate stringSize
 - update related comments
 - none static import
 - move java.util.DecimalDigits to jdk.internal.util.DecimalDigits
 - fix LocalDate.getChars offset
 - improve date toString performance, includes:
   
   java.util.Date.toString
   java.util.Date.toGMTString
   java.time.Instant.toString
   java.time.LocalDate.toString
   java.time.LocalDateTime.toString
   java.time.LocalTime.toString

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

Changes: https://git.openjdk.org/jdk/pull/15658/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15658&range=03
  Stats: 766 lines in 17 files changed: 626 ins; 54 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/15658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658

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

From duke at openjdk.org  Tue Sep 12 01:31:31 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 01:31:31 GMT
Subject: RFR: 8315999: Improve Date toString performance [v5]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

??? has updated the pull request incrementally with two additional commits since the last revision:

 - revert un-related changes
 - revert un-related changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/b26cb857..2a617db5

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

  Stats: 79 lines in 5 files changed: 36 ins; 40 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658

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

From duke at openjdk.org  Tue Sep 12 01:36:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 01:36:10 GMT
Subject: RFR: 8315999: Improve Date toString performance [v6]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

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

  revert un-related changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/2a617db5..26d7c7c0

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

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

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

From bpb at openjdk.org  Tue Sep 12 01:39:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 12 Sep 2023 01:39:40 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 22:22:47 GMT, Brian Burkhalter  wrote:

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 479:

> 477:     if (access == java_io_FileSystem_ACCESS_READ ||
> 478:         access == java_io_FileSystem_ACCESS_EXECUTE) {
> 479:         return _waccess(pathbuf, 0) == 0 ? enable : JNI_FALSE;

Here `enable` is returned for backward compatibility, but per the specification it seems that `JNI_TRUE` should be returned instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15673#discussion_r1322263371

From dholmes at openjdk.org  Tue Sep 12 02:05:41 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Sep 2023 02:05:41 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <6ay7PmY4OxewnaOmKJ3QyrClRC0BqoRSBcUOoCkZvG0=.b043f2a6-0244-4381-be99-9202e457938c@github.com>
References: 
 <6ay7PmY4OxewnaOmKJ3QyrClRC0BqoRSBcUOoCkZvG0=.b043f2a6-0244-4381-be99-9202e457938c@github.com>
Message-ID: 

On Thu, 31 Aug 2023 10:02:45 GMT, chenggwang  wrote:

>> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous and makes you think of Phaser. My intention is that each generation of CyclicBarrier barrierCommand can change. Let me give you a scenario
>> For example, the U.S. Army 'Gordon Sullivan Cup'.
>> Five tanks competing.
>> 1. The first round is for artillery strikes against targets.
>> 2. Second round of anti-aircraft machine gun targets.
>> 3. The third round is minefield racing.
>> The scoring criteria are different for each round, so the CyclicBarrier's barrierCommand should be different for each round. But in the current code, `private final Runnable barrierCommand`, constructing the CyclicBarrier instance is already determined to be unchangeable.
>
>> As I wrote in the JBS issue and as Alan mentioned again above you can use the single `BarrierAction` object to track the state changes and count the generations/phase:
>> 
>> ```
>> Runnable barrierAction = new Runnable() {
>>   int phase = 0;
>>   public void run() {
>>     switch(phase++) {
>>       case 0: doArtillery(); break;
>>       case 1: doAntiAircraft(); nreak;
>>       case 2: doMinefield(); break;
>>     }
>>    void doArtillery() { ... }
>>    ...
>>   }
>> ```
>> 
>> I do not believe there is sufficient justification for expanding the `CyclicBarrier` API as proposed.
>> 
>> Happy to hear what @DougLea and @Martin-Buchholz think about this though.
> 
> Thank you @dholmes-ora @viktorklang-ora Your proposal is indeed a good solution! Enhancements and improvements became less urgent.

@chenggwang can you please close this PR and the associated Enhancement request. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1714854353

From duke at openjdk.org  Tue Sep 12 03:06:02 2023
From: duke at openjdk.org (duke)
Date: Tue, 12 Sep 2023 03:06:02 GMT
Subject: Withdrawn: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Apr 2022 00:32:25 GMT, Brent Christian  wrote:

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Tue Sep 12 06:30:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Sep 2023 06:30:38 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist
In-Reply-To: 
References: 
 
Message-ID: <5nGQ3XRmhjhiYRl4Y4IvGQ1Qu24kQmfMoLdNNdOiWPc=.dc573a6c-e552-426d-bb94-e1f2a97e2a9d@github.com>

On Tue, 12 Sep 2023 01:36:34 GMT, Brian Burkhalter  wrote:

>> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.
>
> src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 479:
> 
>> 477:     if (access == java_io_FileSystem_ACCESS_READ ||
>> 478:         access == java_io_FileSystem_ACCESS_EXECUTE) {
>> 479:         return _waccess(pathbuf, 0) == 0 ? enable : JNI_FALSE;
> 
> Here `enable` is returned for backward compatibility, but per the specification it seems that `JNI_TRUE` should be returned instead.

I don't think this is right, at least it doesn't work with ACLs and file system security so it can't test if the file is executable. Also I have a concern about mixing win32 and C runtime functions here.  The main issue with these setXXX methods is that don't map to DOS file attributes or ACL based security so they will need to fail for some cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15673#discussion_r1322486689

From alanb at openjdk.org  Tue Sep 12 07:21:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Sep 2023 07:21:50 GMT
Subject: Integrated: 8315938: Deprecate for removal Unsafe methods that have
 standard APIs for many releases
In-Reply-To: 
References: 
Message-ID: 

On Fri, 8 Sep 2023 15:54:05 GMT, Alan Bateman  wrote:

> There are several methods defined by sun.misc.Unsafe that have standard API equivalents for many years and releases. The change proposed here is to deprecate, for removal, the park, unpark, getLoadAverage, loadFence, storeFence, and fullFence methods. Code using these methods should move to LockSupport.park/unpark (Java 5), OperatingSystemMXBean.getSystemLoadAverage (Java 6), and VarHandles xxxFence methods (Java 9).
> 
> The following is a summary of a search of 175973022 classes in 484751 artifacts to get a sense of the usage of these methods.
> 
> - 1290 usages of Unsafe.park. 1195 are libraries that have re-packaged some version of ForkJoinPool, maybe from the jsr166 repo, maybe an older JDK release. In the remaining, only Ehcache stands out with 29 matches. It seems to be one usage but the library seems to copied/shaded into other artifacts.
> 
> - 1322 usages of Unsafe.unpark. 1243 are re-packaged ForkJoinPool. 29 occurrences are Encache, again one usage but the library seems to copied/shaded into other artifacts.
> 
> - 22 usages of Unsafe.getLoadAverage. Most of these are one usage in many published versions of Apache HBase.
> 
> - 339 usages of Unsafe.loadFence, 1057 usages of Unsafe.storeFence, 517 usages of Unsafe.fullFence. A handful of these are libraries with copies of j.u.concurrent, the rest seem to be high performance libraries that support older JDK releases or just haven't been updated to use VarHandles yet.

This pull request has now been integrated.

Changeset: d08258f7
Author:    Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/d08258f735053142e43896c16cf7c6155cd9c35f
Stats:     22 lines in 1 file changed: 20 ins; 1 del; 1 mod

8315938: Deprecate for removal Unsafe methods that have standard APIs for many releases

Reviewed-by: mchung, psandoz, iris

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

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

From prappo at openjdk.org  Tue Sep 12 08:14:58 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 12 Sep 2023 08:14:58 GMT
Subject: Integrated: 8316038: Fix doc typos in java.io.Console and
 java.util.Scanner
In-Reply-To: 
References: 
Message-ID: <6uKwqri8av2msqo6rXOLB4pD0pv2ZDwMI4zK3uz6O7A=.35e23f3e-da9d-496e-a1d9-67bfd49ea805@github.com>

On Mon, 11 Sep 2023 17:58:20 GMT, Pavel Rappo  wrote:

> Please review this trivial PR.

This pull request has now been integrated.

Changeset: f55e7994
Author:    Pavel Rappo 
URL:       https://git.openjdk.org/jdk/commit/f55e799491c39dcaf7b3935b6d560ee0a3239191
Stats:     7 lines in 2 files changed: 0 ins; 0 del; 7 mod

8316038: Fix doc typos in java.io.Console and java.util.Scanner

Reviewed-by: bpb, naoto, iris

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

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

From simone.bordet at gmail.com  Tue Sep 12 08:35:19 2023
From: simone.bordet at gmail.com (Simone Bordet)
Date: Tue, 12 Sep 2023 10:35:19 +0200
Subject: Java 21 clinit deadlock
In-Reply-To: 
References: 
 <77f901c7-5bb8-4703-8c64-b331913516b6@oracle.com>
 
Message-ID: 

David,

On Mon, Sep 11, 2023 at 9:29?AM Simone Bordet  wrote:
>
> Hi,
>
> On Mon, Sep 11, 2023 at 7:22?AM David Holmes  wrote:
> > I've looked at the dump and there is no sign that the MutableHttpFields
> > is actively in use. It suggests to me that class initialization has
> > failed but the class state has not been correctly updated and the
> > waiters released. There were some changes in JDK 21 about how failures
> > in this area were handled, so it is possible I/we got something wrong.
> > Is it possible to try running this with additional logging enabled e.g.
> >
> > -Xlog:class+init=debug -Xlog:exceptions=debug
>
> We will try this, than you!

Here is another failed run:
JVM threads dump: https://gist.github.com/olamy/b3e20a76f0fc77232882b9be95db47e1
JVM output (gist is truncated, download full file):
https://gist.githubusercontent.com/olamy/86f0a1215c722e5e9acf96cae597422e/raw/4404693c39fd767122d34a7a3dde1d797afa6f25/gistfile1.txt

The JVM stops outputting at 2.360s, then we have a Jetty idle timeout
after 30 seconds, then we see:

[51.472s][debug][exceptions] Thread::clear_pending_exception: cleared
exception:java.lang.VirtualMachineError '.

And then more log lines follow after another 5 minutes.

Let us know your findings.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From aturbanov at openjdk.org  Tue Sep 12 08:49:41 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Sep 2023 08:49:41 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation
In-Reply-To: 
References: 
Message-ID: 

On Sat, 9 Sep 2023 14:33:53 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

test/jdk/java/util/zip/ZipFile/MissingZIP64EntriesTest.java line 198:

> 196:      * actual value is stored in the Zip64 Extra Header
> 197:      */
> 198:     private static final int  ZIP64_MAGICCOUNT = 0xFFFF;

Suggestion:

    private static final int ZIP64_MAGICCOUNT = 0xFFFF;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15650#discussion_r1322670868

From redestad at openjdk.org  Tue Sep 12 10:14:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Sep 2023 10:14:42 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 12 Sep 2023 01:00:39 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   little-endian

Running some additional testing. This mostly looks fine. 

One issue is that you're swapping the byte-order in `DecimalDigits::DIGITS` but not in `OctalDigits` and `HexDigits`. I think we need to keep these internally consistent to avoid surprises.

I also would like to see performance numbers of the byte order swap evaluated in isolation. I suspect the real effect is small and might be due to JIT noise rather than a real effect, and that this swap got rushed in without solid evidence that it helps. 

If there's no significant performance difference I would prefer if we kept `DecimalDigits::DIGITS` big-endian encoded - which is more intuitive to most - and adjust code depending on `DecimalDigits::digitPair` to use `ByteArray` rather than `ByteArrayLittleEndian`.

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715419335

From redestad at openjdk.org  Tue Sep 12 10:45:53 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Sep 2023 10:45:53 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v18]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 12 Sep 2023 10:11:53 GMT, Claes Redestad  wrote:

> If there's no significant performance difference I would prefer if we kept `DecimalDigits::DIGITS` big-endian encoded - which is more intuitive to most - and adjust code depending on `DecimalDigits::digitPair` to use `ByteArray` rather than `ByteArrayLittleEndian`.

Just a datapoint but when I test implementing `HexFormat::toHexDigits` using either `ByteArray` or `ByteArrayLittleEndian` then the difference is in the noise:


Name                           Cnt  Base   Error   Test   Error  Unit   Diff%
HexFormatBench.toHexDigitsLong  15 1,950 ? 0,012  1,941 ? 0,016 us/op    0,5% (p = 0,081 )

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715482633

From jvernee at openjdk.org  Tue Sep 12 10:49:38 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 12 Sep 2023 10:49:38 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v21]
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 two additional commits since the last revision:

 - add missing space + reflow lines
 - Fix typo
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/0e702f06..e68b95c1

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

  Stats: 2 lines in 1 file changed: 1 ins; 0 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 duke at openjdk.org  Tue Sep 12 13:05:19 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 13:05:19 GMT
Subject: RFR: 8315999: Improve Date toString performance [v7]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

??? has updated the pull request incrementally with two additional commits since the last revision:

 - improved DateTimeFormatter.format
 - improved ISO_INSTANT format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/26d7c7c0..8b3f0637

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

  Stats: 459 lines in 6 files changed: 393 ins; 44 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/15658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658

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

From duke at openjdk.org  Tue Sep 12 13:13:43 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 13:13:43 GMT
Subject: RFR: 8315999: Improve Date toString performance [v7]
In-Reply-To: <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com>
 <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com>
Message-ID: 

On Mon, 11 Sep 2023 14:59:25 GMT, ???  wrote:

>> The performance of optimizing DateTimeFormatter cannot be as fast as using ixed-length buffer directly.
>
> Of course, the optimization of DateTimeFormatter is more general, and we can spend time doing it later. The format of toString is fixed, we can not use DateTimeFormatter.

> Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here?
> 
> Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications.

I submitted an optimization for the commonly used format of DateTimeFormatter::format

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323021409

From duke at openjdk.org  Tue Sep 12 13:27:29 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 13:27:29 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v19]
In-Reply-To: 
References: 
Message-ID: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>

> Some codes in core libs are duplicated, including:
> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
> java.util.DecimalDigits::size -> java.lang.Long.stringSize
> 
> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
> https://github.com/openjdk/jdk/pull/15555

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

  little-endian

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15651/files
  - new: https://git.openjdk.org/jdk/pull/15651/files/93ed81da..c68c4e81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15651&range=17-18

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

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

From duke at openjdk.org  Tue Sep 12 13:27:53 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 13:27:53 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v18]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 12 Sep 2023 10:11:53 GMT, Claes Redestad  wrote:

> Running some additional testing. This mostly looks fine.
> 
> One issue is that you're swapping the byte-order in `DecimalDigits::DIGITS` but not in `OctalDigits` and `HexDigits`. I think we need to keep these internally consistent to avoid surprises.
> 
> I also would like to see performance numbers of the byte order swap evaluated in isolation. I suspect the real effect is small and might be due to JIT noise rather than a real effect, and that this swap got rushed in without solid evidence that it helps.
> 
> If there's no significant performance difference I would prefer if we kept `DecimalDigits::DIGITS` big-endian encoded - which is more intuitive to most - and adjust code depending on `DecimalDigits::digitPair` to use `ByteArray` rather than `ByteArrayLittleEndian`.

I prefer to use little endian,  most environments are little endian. Changes to HexDigit will have to wait until #PR 14745 is merged.

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715721750

From rriggs at openjdk.org  Tue Sep 12 13:51:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Sep 2023 13:51:40 GMT
Subject: RFR: 8315968: Consolidate java.util.Digits and
 StringLatin1::PACKED_DIGITS [v19]
In-Reply-To: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
References: 
 <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
Message-ID: <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com>

On Tue, 12 Sep 2023 13:27:29 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   little-endian

Please update this PR title and description to indicate this refactoring to move to jdk.internal.util.
I can update the Jira title and description to match after that.

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715764494

From rriggs at openjdk.org  Tue Sep 12 13:57:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Sep 2023 13:57:44 GMT
Subject: RFR: 8315999: Improve Date toString performance [v7]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: 

On Tue, 12 Sep 2023 13:05:19 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - improved DateTimeFormatter.format
>  - improved ISO_INSTANT format

You haven't make the case for these changes, please describe the use cases when performance is a significant constraint on application performance.  
The changes largely just add more code to maintain without otherwise adding sufficient value.

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1715774423

From duke at openjdk.org  Tue Sep 12 14:15:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 14:15:42 GMT
Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and
 refactor to reduce duplication [v19]
In-Reply-To: <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com>
References: 
 <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
 <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com>
Message-ID: 

On Tue, 12 Sep 2023 13:49:09 GMT, Roger Riggs  wrote:

> Please update this PR title and description to indicate this refactoring to move to jdk.internal.util. I can update the Jira title and description to match after that.

The title has been updated, please help update the title of JIRA

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715808794

From rriggs at openjdk.org  Tue Sep 12 14:19:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Sep 2023 14:19:41 GMT
Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and
 refactor to reduce duplication [v19]
In-Reply-To: 
References: 
 <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
 <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com>
 
Message-ID: 

On Tue, 12 Sep 2023 14:13:06 GMT, ???  wrote:

> The title has been updated, please help update the title of JIRA

The description needs an update too.

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715814638

From liach at openjdk.org  Tue Sep 12 14:27:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Sep 2023 14:27:44 GMT
Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and
 refactor to reduce duplication [v19]
In-Reply-To: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
References: 
 <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
Message-ID: 

On Tue, 12 Sep 2023 13:27:29 GMT, ???  wrote:

>> Some codes in core libs are duplicated, including:
>> java.util.DecimalDigits::DIGITS -> java.lang.StringLatin1.PACKED_DIGITS
>> java.util.DecimalDigits::size -> java.lang.Long.stringSize
>> 
>> We can reduce duplication through JavaLangAccess, which is also needed in other places, such as:
>> https://github.com/openjdk/jdk/pull/15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   little-endian

I have updated the JBS bug title and explicitly stated the actions in this patch:
1. Move Digits to jdk.internal.util
2. Keep the tables in DecimalDigits and access via a new digitPair static method
3. Change the DecimalDigits' table to be LE (instead of BE) and update implementation

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715829791

From duke at openjdk.org  Tue Sep 12 14:33:44 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 14:33:44 GMT
Subject: RFR: 8315999: Improve Date toString performance [v7]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 
Message-ID: 

On Tue, 12 Sep 2023 13:54:34 GMT, Roger Riggs  wrote:

> You haven't make the case for these changes, please describe the use cases when performance is a significant constraint on application performance. The changes largely just add more code to maintain without otherwise adding sufficient value.

Many scenarios require this optimization, such as:

1. The open source project [datax](https://github.com/alibaba/datax) is a data integration engine we maintain. When the input is a Date but the target type is String, the Date must be converted to String. In the flame graph below, commons-lang's FastDateFormat::format method consumes most of the time. It will be similar if replaced by DateTimeFormatter::format.
![image](https://github.com/openjdk/jdk/assets/1166785/1063aacf-c770-4c2d-9920-297be65ac6b0)


2. JSON libraries such as gson/jackson/fastjson need to convert Date/Instant into String, and format/toString usually takes up a relatively large proportion of time.

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1715842265

From simonis at openjdk.org  Tue Sep 12 14:43:42 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 12 Sep 2023 14:43:42 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v4]
In-Reply-To: <4tTHtnDKfaPHhUpYVq4RO-3SS2PcNrCPDSwillvAyA8=.323fed3c-5115-470d-989a-cbbdc99027c9@github.com>
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
 <4tTHtnDKfaPHhUpYVq4RO-3SS2PcNrCPDSwillvAyA8=.323fed3c-5115-470d-989a-cbbdc99027c9@github.com>
Message-ID: 

On Mon, 11 Sep 2023 17:52:56 GMT, Mandy Chung  wrote:

>> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`.   The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use).   If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size.   This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

Looks good. Thanks for doing the proposed changes.

src/java.base/share/classes/java/lang/StackStreamFactory.java line 766:

> 764:         @Override
> 765:         protected int batchSize(int lastBatchFrameCount) {
> 766:             // this method is only called when the caller class is not found in

Minor nit: start sentence with an uppercase letter.

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

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15642#pullrequestreview-1622420644
PR Review Comment: https://git.openjdk.org/jdk/pull/15642#discussion_r1323147343

From duke at openjdk.org  Tue Sep 12 14:54:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 14:54:42 GMT
Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and
 refactor to reduce duplication [v19]
In-Reply-To: 
References: 
 <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
 <_ArpJQKqE_bcjQYkVZadLH531YA0zKx1JiHkyFyAm0E=.0990fd2c-7996-4a43-a7f1-582dfab5abb4@github.com>
 
 
Message-ID: <6T9e81P8e5rZ-n_QQZWs82MKWeC2PxxXjONvN377Un8=.155a3fe0-b325-49be-81cf-256473b8413d@github.com>

On Tue, 12 Sep 2023 14:16:27 GMT, Roger Riggs  wrote:

> > The title has been updated, please help update the title of JIRA
> 
> The description needs an update too.

The description has also been updated

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715880514

From alanb at openjdk.org  Tue Sep 12 15:02:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Sep 2023 15:02:31 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v2]
In-Reply-To: 
References: 
Message-ID: 

> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
> 
> The change is straight-forward, it's just additional bit to indicate that the parking/parked/pinned states are timed. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.

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

 - Merge
 - Remove unecessary RF from test
 - Merge
 - Merge
 - Remove tab
 - Cleanup comments
 - Merge
 - Spurious tab
 - Test improvements
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14978/files
  - new: https://git.openjdk.org/jdk/pull/14978/files/872ab6a7..7b9e0d5a

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

  Stats: 80726 lines in 2543 files changed: 46386 ins; 17285 del; 17055 mod
  Patch: https://git.openjdk.org/jdk/pull/14978.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14978/head:pull/14978

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

From redestad at openjdk.org  Tue Sep 12 15:35:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Sep 2023 15:35:41 GMT
Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and
 refactor to reduce duplication [v18]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 12 Sep 2023 13:24:56 GMT, ???  wrote:

> I prefer to use little endian, most environments are little endian. Changes to HexDigit will have to wait until #PR 14745 is merged.

I don't have a very strong opinion except that we should be consistent across these related implementations. If you could either include `OctalDigits` changes in #14745 or prepare a separate PR for it I'm OK with this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15651#issuecomment-1715954790

From redestad at openjdk.org  Tue Sep 12 15:58:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Sep 2023 15:58:42 GMT
Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and
 refactor to reduce duplication [v19]
In-Reply-To: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
References: 
 <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
Message-ID: 

On Tue, 12 Sep 2023 13:27:29 GMT, ???  wrote:

>> java.util.DecimalDigits::DIGITS and java.lang.StringLatin1.PACKED_DIGITS are duplicates, We need to move java.util.Digits/OctalDigits/DecimalDigits/HexDigits to the jdk.internal.util package, and modify these classes to public class, so that classes in other packages can also access them.
>> 
>> DecimalDigits::DIGITS provides a new digitPair static method, used to replace StringLatin1.PACKED_DIGITS access.
>> 
>> In order to be consistent with the original StringLatin1.PACKED_DIGITS, OctalDigits::DIGITS and DecimalDigits::DIGITS are modified to little-endian. HexDigits::DIGITS will also be modified after PR #14745 is merged.
>> 
>> These changes will be used by PR #15658 #15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   little-endian

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1622597772

From rriggs at openjdk.org  Tue Sep 12 16:06:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Sep 2023 16:06:43 GMT
Subject: RFR: 8315968: Move java.util.Digits to jdk.internal.util and
 refactor to reduce duplication [v19]
In-Reply-To: <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
References: 
 <_FCWeTPds9PIl2TW0urI9F5vVejboPz_Ib7I_3ITZHg=.8e912960-3699-41f7-87ea-716e66442373@github.com>
Message-ID: 

On Tue, 12 Sep 2023 13:27:29 GMT, ???  wrote:

>> java.util.DecimalDigits::DIGITS and java.lang.StringLatin1.PACKED_DIGITS are duplicates, We need to move java.util.Digits/OctalDigits/DecimalDigits/HexDigits to the jdk.internal.util package, and modify these classes to public class, so that classes in other packages can also access them.
>> 
>> DecimalDigits::DIGITS provides a new digitPair static method, used to replace StringLatin1.PACKED_DIGITS access.
>> 
>> In order to be consistent with the original StringLatin1.PACKED_DIGITS, OctalDigits::DIGITS and DecimalDigits::DIGITS are modified to little-endian. HexDigits::DIGITS will also be modified after PR #14745 is merged.
>> 
>> These changes will be used by PR #15658 #15555
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   little-endian

Thanks for the updates.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15651#pullrequestreview-1622614379

From martin at openjdk.org  Tue Sep 12 16:14:44 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Tue, 12 Sep 2023 16:14:44 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang  wrote:

> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous and makes you think of Phaser. My intention is that each generation of CyclicBarrier barrierCommand can change. Let me give you a scenario
> For example, the U.S. Army 'Gordon Sullivan Cup'.
> Five tanks competing.
> 1. The first round is for artillery strikes against targets.
> 2. Second round of anti-aircraft machine gun targets.
> 3. The third round is minefield racing.
> The scoring criteria are different for each round, so the CyclicBarrier's barrierCommand should be different for each round. But in the current code, `private final Runnable barrierCommand`, constructing the CyclicBarrier instance is already determined to be unchangeable.

We should try to retain designed immutability in concurrency classes.
Having had the experience of having fixed many bugs with knobs tunable at runtime.
If you make a field mutable, you need to think not just about "set", but also about "compare and set", "freeze" and security implications of adding a new form of attack.

So let's leave CyclicBarrier unchanged.

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

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1716024120

From mchung at openjdk.org  Tue Sep 12 16:16:41 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 12 Sep 2023 16:16:41 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v4]
In-Reply-To: 
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
 <4tTHtnDKfaPHhUpYVq4RO-3SS2PcNrCPDSwillvAyA8=.323fed3c-5115-470d-989a-cbbdc99027c9@github.com>
 
Message-ID: 

On Tue, 12 Sep 2023 14:38:07 GMT, Volker Simonis  wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/java/lang/StackStreamFactory.java line 766:
> 
>> 764:         @Override
>> 765:         protected int batchSize(int lastBatchFrameCount) {
>> 766:             // this method is only called when the caller class is not found in
> 
> Minor nit: start sentence with an uppercase letter.

I'll leave it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15642#discussion_r1323277241

From mchung at openjdk.org  Tue Sep 12 16:27:52 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 12 Sep 2023 16:27:52 GMT
Subject: Integrated: 8285447: StackWalker minimal batch size should be
 optimized for getCallerClass
In-Reply-To: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
Message-ID: 

On Fri, 8 Sep 2023 16:57:14 GMT, Mandy Chung  wrote:

> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`.   The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use).   If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size.   This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench.

This pull request has now been integrated.

Changeset: d75d9774
Author:    Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/d75d9774c806e4bf73caa69cd78c31a132e4c812
Stats:     83 lines in 3 files changed: 65 ins; 12 del; 6 mod

8285447: StackWalker minimal batch size should be optimized for getCallerClass

Reviewed-by: simonis

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

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

From mchung at openjdk.org  Tue Sep 12 16:37:28 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 12 Sep 2023 16:37:28 GMT
Subject: RFR: 8315810: Reimplement
 sun.reflect.ReflectionFactory::newConstructorForSerialization with method
 handles [v2]
In-Reply-To: 
References: 
Message-ID: 

> This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles.
> 
> This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization.  This change will allow such VM hack to be removed.
> 
> A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue.   I expect this change has very low compatibility risk.   This system property is undocumented and will be removed in a future release.

Mandy Chung has updated the pull request with a new target base 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' of https://github.com/openjdk/jdk into reflect-serializable-ctor
 - minor cleanup
 - Reimplement ReflectionFactory::newConstructorForSerialization with method handle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15600/files
  - new: https://git.openjdk.org/jdk/pull/15600/files/e98b5528..fb3bf590

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

  Stats: 33895 lines in 1007 files changed: 19846 ins; 9174 del; 4875 mod
  Patch: https://git.openjdk.org/jdk/pull/15600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15600/head:pull/15600

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

From duke at openjdk.org  Tue Sep 12 16:38:00 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 16:38:00 GMT
Subject: Integrated: 8315968: Move java.util.Digits to jdk.internal.util and
 refactor to reduce duplication
In-Reply-To: 
References: 
Message-ID: 

On Sun, 10 Sep 2023 16:15:01 GMT, ???  wrote:

> java.util.DecimalDigits::DIGITS and java.lang.StringLatin1.PACKED_DIGITS are duplicates, We need to move java.util.Digits/OctalDigits/DecimalDigits/HexDigits to the jdk.internal.util package, and modify these classes to public class, so that classes in other packages can also access them.
> 
> DecimalDigits::DIGITS provides a new digitPair static method, used to replace StringLatin1.PACKED_DIGITS access.
> 
> In order to be consistent with the original StringLatin1.PACKED_DIGITS, OctalDigits::DIGITS and DecimalDigits::DIGITS are modified to little-endian. HexDigits::DIGITS will also be modified after PR #14745 is merged.
> 
> These changes will be used by PR #15658 #15555

This pull request has now been integrated.

Changeset: e0845163
Author:    shaojin.wensj 
Committer: Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/e0845163aa57cc8f68b11e1a553885676358f2a6
Stats:     530 lines in 10 files changed: 257 ins; 260 del; 13 mod

8315968: Move java.util.Digits to jdk.internal.util and refactor to reduce duplication

Reviewed-by: rriggs, liach, redestad

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

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

From duke at openjdk.org  Tue Sep 12 16:58:20 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 16:58:20 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v15]
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: 

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.toString"
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * cpu : aliyun yitian 710 (aarch64)
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

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

 - merge from master
 - Merge branch 'master' into optimization_for_uuid_to_string
   
   # Conflicts:
   #	src/java.base/share/classes/java/util/UUID.java
   #	src/java.base/share/classes/jdk/internal/util/HexDigits.java
 - lo | hi => hi | lo
 - add DIGITS description
 - reversed how & hi
 - Merge branch 'master' into optimization_for_uuid_to_string
 - remove redundant parentheses
 - fix java doc, big-endian -> little-endian
 - Merge branch 'master' into optimization_for_uuid_to_string
 - use ByteArrayLittleEndian
 - ... and 9 more: https://git.openjdk.org/jdk/compare/e0845163...4f6ed3e6

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

Changes: https://git.openjdk.org/jdk/pull/14745/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14745&range=14
  Stats: 55 lines in 2 files changed: 5 ins; 12 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/14745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14745/head:pull/14745

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

From duke at openjdk.org  Tue Sep 12 17:07:40 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 17:07:40 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v14]
In-Reply-To: 
References: 
Message-ID: 

> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal.
> 
> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance.
> 
> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering.
> 
> The performance data is as follows: 
> 
> ## 1. benchmark script
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.math.BigDecimals.*ToPlainString"
> make test TEST="micro:java.math.BigDecimals.*ToEngineering"
> 
> 
> ## 2. benchmark environment
> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i)
> * cpu intel xeon sapphire rapids (x64)
> 
> ## 3. benchmark result
> 
> -BigDecimals.testHugeToPlainString         avgt   15   188.691 ?  0.822  ns/op  (baseline)
> -BigDecimals.testLargeToPlainString        avgt   15    36.656 ?  0.065  ns/op
> -BigDecimals.testSmallToPlainString        avgt   15    34.342 ?  0.068  ns/op
> -BigDecimals.testToPlainString             avgt   15  1719.494 ? 24.886  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
> +BigDecimals.testHugeToPlainString         avgt   15   133.972 ?  0.328  ns/op (+40.84%)
> +BigDecimals.testLargeToPlainString        avgt   15    14.957 ?  0.047  ns/op (145.07%)
> +BigDecimals.testSmallToPlainString        avgt   15    12.045 ?  0.036  ns/op (+185.11)
> +BigDecimals.testToPlainString             avgt   15  1643.500 ?  3.217  ns/op (+4.62%)
> 
> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
> -BigDecimals.testHugeToEngineeringString   avgt   15   207.621 ?  5.018  ns/op
> -BigDecimals.testLargeToEngineeringString  avgt   15    35.658 ?  3.144  ns/op
> -BigDecimals.testSmallToEngineeringString  avgt   15    15.142 ?  0.053  ns/op
> -BigDecimals.testToEngineeringString       avgt   15  1813.959 ? 12.842  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
> +BigDecimals.testHugeToEngineeringString   avgt   15   142.110 ?  0.987  ns/op (+45.09%)
> +BigDecimals.testLargeToEngineeringString  avgt   15    12.509 ?  0.056  ns/op (+185.05%)
> +BigDecimals.testSmallToEngineer...

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

 - merge from master
 - Merge branch 'master' into optimization_for_decimal_to_string
 - improved huge BigDecimal to string
 - Merge branch 'master' into optimization_for_decimal_to_string
 - fix scale 19 error & add testcases
 - bug fix & add testcases
 - remove jla.newStringLatin1NoRepl
 - rename jla.digit to digitPair
 - fix adjusted >= Integer.MAX_VALUE
 - Continue to optimize and reduce duplicate code
 - ... and 7 more: https://git.openjdk.org/jdk/compare/3925ed53...4ffbb235

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15555/files
  - new: https://git.openjdk.org/jdk/pull/15555/files/a3035e8f..4ffbb235

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

  Stats: 4933 lines in 136 files changed: 3138 ins; 1125 del; 670 mod
  Patch: https://git.openjdk.org/jdk/pull/15555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555

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

From duke at openjdk.org  Tue Sep 12 17:17:23 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 17:17:23 GMT
Subject: RFR: 8315999: Improve Date toString performance [v8]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

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

 - merge from master & revert DateTimeFormatterBuilder
 - Merge branch 'master' into optim_for_date_to_string_2
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/StringUTF16.java
   #	src/java.base/share/classes/jdk/internal/util/DecimalDigits.java
 - improved DateTimeFormatter.format
 - improved ISO_INSTANT format
 - revert un-related changes
 - revert un-related changes
 - revert un-related changes
 - rebase PR #15651 last version
 - base PR #15651 API
 - move java.lang.StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1
 - ... and 8 more: https://git.openjdk.org/jdk/compare/1cd96ce2...9040ea0c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/8b3f0637..9040ea0c

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

  Stats: 1245 lines in 45 files changed: 528 ins; 609 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/15658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658

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

From duke at openjdk.org  Tue Sep 12 17:23:00 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 17:23:00 GMT
Subject: RFR: 8315999: Improve Date toString performance [v9]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com>

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

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

  merge from master

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/9040ea0c..e4c5b67b

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

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

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

From darcy at openjdk.org  Tue Sep 12 17:56:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Sep 2023 17:56:42 GMT
Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well
 documented. [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 8 Sep 2023 21:11:11 GMT, Justin Lu  wrote:

>> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern.
>> 
>> `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified.
>> 
>> The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor.
>> 
>> The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop Unicode from definition, implied

src/java.base/share/classes/java/text/ChoiceFormat.java line 160:

> 158:  * Note:The relation ≤ is not equivalent to <=
> 159:  *
> 160:  * 
Below is an example of constructing a ChoiceFormat with a pattern:

FWIW, in other parts of core libs such as java.lang.Double, I've used a definition list `
` with terms `
` and definitions `
` to represent such grammars.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15392#discussion_r1323380975

From duke at openjdk.org  Tue Sep 12 18:01:50 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 12 Sep 2023 18:01:50 GMT
Subject: RFR: 8315999: Improve Date toString performance [v9]
In-Reply-To: <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com>
Message-ID: 

On Tue, 12 Sep 2023 17:23:00 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge from master

`LocalTime::getNanoChars(byte[],?int,?int)` can?use `DecimalDigits::digitTriple(int)` instead?of a?local?copy of?`DecimalDigits.DIGITS_K`:

src/java.base/share/classes/java/time/LocalTime.java line 141:

> 139:     @Stable
> 140:     static final int[] DIGITS_K = new int[1000];
> 141: 

Suggestion:

src/java.base/share/classes/java/time/LocalTime.java line 179:

> 177:             int c3 = i % 10 + '0';
> 178:             DIGITS_K[i] = c0 + (c1 << 8) + (c2 << 16) + (c3 << 24);
> 179:         }

Suggestion:

src/java.base/share/classes/java/time/LocalTime.java line 1710:

> 1708:                 buf,
> 1709:                 off,
> 1710:                 DIGITS_K[div2] & 0xffffff00 | '.'

Suggestion:

                DecimalDigits.digitTriple(div2) & 0xffffff00 | '.'

src/java.base/share/classes/java/time/LocalTime.java line 1722:

> 1720:             }
> 1721: 
> 1722:             v = DIGITS_K[rem2];

Suggestion:

            v = DecimalDigits.digitTriple(rem2);

src/java.base/share/classes/java/time/LocalTime.java line 1724:

> 1722:             v = DIGITS_K[rem2];
> 1723:         } else {
> 1724:             v = DIGITS_K[div - div2 * 1000];

Suggestion:

            v = DecimalDigits.digitTriple(div - div2 * 1000);

src/java.base/share/classes/java/time/LocalTime.java line 1740:

> 1738:                     buf,
> 1739:                     off,
> 1740:                     DIGITS_K[rem1] & 0xffffff00 | (v >> 24)

Suggestion:

                    DecimalDigits.digitTriple(rem1) & 0xffffff00 | (v >> 24)

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

PR Review: https://git.openjdk.org/jdk/pull/15658#pullrequestreview-1622831447
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323381033
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323381182
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323379816
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323380364
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323380525
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323380651

From jlu at openjdk.org  Tue Sep 12 19:05:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Sep 2023 19:05:28 GMT
Subject: RFR: 6228794: java.text.ChoiceFormat pattern behavior is not well
 documented. [v7]
In-Reply-To: 
References: 
Message-ID: <6J2qTTvtMh6FORDoR7ZpjRQ15IWpvsoc0BrcIhgZ61k=.44f3a00a-550b-4836-ac48-cf16e9fbcf21@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern.
> 
> `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified.
> 
> The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor.
> 
> The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html

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

  Use  description tags to create syntax, include negative symbol in Number section

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15392/files
  - new: https://git.openjdk.org/jdk/pull/15392/files/216e5ac7..ff1be6ad

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

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

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

From rriggs at openjdk.org  Tue Sep 12 19:14:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Sep 2023 19:14:44 GMT
Subject: RFR: 8315810: Reimplement
 sun.reflect.ReflectionFactory::newConstructorForSerialization with method
 handles [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 12 Sep 2023 16:37:28 GMT, Mandy Chung  wrote:

>> This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles.
>> 
>> This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization.  This change will allow such VM hack to be removed.
>> 
>> A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue.   I expect this change has very low compatibility risk.   This system property is undocumented and will be removed in a future release.
>
> Mandy Chung has updated the pull request with a new target base 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' of https://github.com/openjdk/jdk into reflect-serializable-ctor
>  - minor cleanup
>  - Reimplement ReflectionFactory::newConstructorForSerialization with method handle

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 3552:

> 3550:                 }
> 3551:             }
> 3552:             return false;

Does it break encapsulation too much to export and use the same method from jdk.internal.reflect.MethodHandleAccessorFactory.
Maybe not worth it for a small utility method.

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 384:

> 382:                                              getConstructorAnnotations(constructorToCall),
> 383:                                              langReflectAccess.
> 384:                                              getConstructorParameterAnnotations(constructorToCall));

This would be easier to read if either the line length or the indentation was modified.

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 400:

> 398:     }
> 399: 
> 400: 

Extra blank line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1323453214
PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1318801680
PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1318803452

From rriggs at openjdk.org  Tue Sep 12 19:26:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Sep 2023 19:26:47 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v15]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
Message-ID: 

On Tue, 12 Sep 2023 16:58:20 GMT, ???  wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.toString"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - merge from master
>  - Merge branch 'master' into optimization_for_uuid_to_string
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/util/UUID.java
>    #	src/java.base/share/classes/jdk/internal/util/HexDigits.java
>  - lo | hi => hi | lo
>  - add DIGITS description
>  - reversed how & hi
>  - Merge branch 'master' into optimization_for_uuid_to_string
>  - remove redundant parentheses
>  - fix java doc, big-endian -> little-endian
>  - Merge branch 'master' into optimization_for_uuid_to_string
>  - use ByteArrayLittleEndian
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/e0845163...4f6ed3e6

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 112:

> 110:                 | (DIGITS[b1 & 0xff] << 16)
> 111:                 | (((long) DIGITS[b2 & 0xff]) << 32)
> 112:                 | (((long) DIGITS[b3 & 0xff]) << 48);

Can you reverse the order of these source lines to put the shifts of the higher order bits before the lower order bit shifts.  `3333222211110000`. Its easier to understand where the bits end up in the long.
The rest of the change is better focused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1323465285

From asemenyuk at openjdk.org  Tue Sep 12 19:56:05 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 12 Sep 2023 19:56:05 GMT
Subject: RFR: 8301247: JPackage app-image exe launches multiple exe's in JDK
 17+
Message-ID: 

On Windows, restart app launcher in a way that when the parent app launcher process terminates, the child app launcher process is automatically terminated.

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

Commit messages:
 - 8301247: JPackage app-image exe launches multiple exe's in JDK 17+

Changes: https://git.openjdk.org/jdk/pull/15690/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15690&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301247
  Stats: 515 lines in 5 files changed: 282 ins; 217 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/15690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15690/head:pull/15690

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

From aturbanov at openjdk.org  Tue Sep 12 20:13:01 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Sep 2023 20:13:01 GMT
Subject: RFR: 8316144: Remove unused field
 jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element._Depth
Message-ID: 

A field `short _Depth` in the `jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element` class is unused and can be removed.

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

Commit messages:
 - [PATCH] Remove unused field jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element#_Depth

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

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

From erikj at openjdk.org  Tue Sep 12 20:18:51 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 20:18:51 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: 
References: 
Message-ID: 

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson  wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Thanks for reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1716362585

From erikj at openjdk.org  Tue Sep 12 20:18:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 20:18:52 GMT
Subject: Integrated: 8267174: Many test files have the wrong Copyright header
In-Reply-To: 
References: 
Message-ID: <0l5wbPPACAFDpuzCNnCNkr_RJ35CFXxPC9EpiVFt_Ao=.fbfbc877-43fd-4706-9d0d-bace4d004632@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson  wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

This pull request has now been integrated.

Changeset: 020255a7
Author:    Erik Joelsson 
URL:       https://git.openjdk.org/jdk/commit/020255a72dc374ba0bdd44772047f14a8bfe69a9
Stats:     1944 lines in 648 files changed: 0 ins; 1296 del; 648 mod

8267174: Many test files have the wrong Copyright header

Reviewed-by: valeriep, aivanov, iris, dholmes, ihse

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

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

From mchung at openjdk.org  Tue Sep 12 20:37:42 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 12 Sep 2023 20:37:42 GMT
Subject: RFR: 8315810: Reimplement
 sun.reflect.ReflectionFactory::newConstructorForSerialization with method
 handles [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <3eYOcqGU6QKrl3DK8Oar-BDRa4UNgEmbJoewr95vvdY=.4af39a84-04e1-4193-bb83-b487677bc72b@github.com>

On Tue, 12 Sep 2023 19:11:30 GMT, Roger Riggs  wrote:

>> Mandy Chung has updated the pull request with a new target base 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' of https://github.com/openjdk/jdk into reflect-serializable-ctor
>>  - minor cleanup
>>  - Reimplement ReflectionFactory::newConstructorForSerialization with method handle
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 3552:
> 
>> 3550:                 }
>> 3551:             }
>> 3552:             return false;
> 
> Does it break encapsulation too much to export and use the same method from jdk.internal.reflect.MethodHandleAccessorFactory.
> Maybe not worth it for a small utility method.

It's a small utility and I think it's ok to leave it this way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15600#discussion_r1323533889

From bchristi at openjdk.org  Tue Sep 12 21:08:53 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 12 Sep 2023 21:08:53 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v4]
In-Reply-To: <4tTHtnDKfaPHhUpYVq4RO-3SS2PcNrCPDSwillvAyA8=.323fed3c-5115-470d-989a-cbbdc99027c9@github.com>
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
 <4tTHtnDKfaPHhUpYVq4RO-3SS2PcNrCPDSwillvAyA8=.323fed3c-5115-470d-989a-cbbdc99027c9@github.com>
Message-ID: 

On Mon, 11 Sep 2023 17:52:56 GMT, Mandy Chung  wrote:

>> Typically it will find the caller class at the second stack frame from the frame of executing `StackWalker::getCallerClass`.   The initial size of the buffer can be changed from 8 to 4 (the top 2 elements are reserved for implementation use).   If it fetches another batch, `getCallerClass` may be invoked via core reflection, so subsequent batches can be increased to a larger size.   This PR also moves the benchmark for `getCallerClass` in its own file because it does not need to test with different depth and can be separated from StackWalkBench.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

test/micro/org/openjdk/bench/java/lang/CallerClassBench.java line 45:

> 43: public class CallerClassBench {
> 44:     static final StackWalker INST = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> 45: 

Could `DROP_METHOD_INFO` also be used here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15642#discussion_r1323574924

From mchung at openjdk.org  Tue Sep 12 21:12:52 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 12 Sep 2023 21:12:52 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v4]
In-Reply-To: 
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
 <4tTHtnDKfaPHhUpYVq4RO-3SS2PcNrCPDSwillvAyA8=.323fed3c-5115-470d-989a-cbbdc99027c9@github.com>
 
Message-ID: 

On Tue, 12 Sep 2023 21:06:15 GMT, Brent Christian  wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> test/micro/org/openjdk/bench/java/lang/CallerClassBench.java line 45:
> 
>> 43: public class CallerClassBench {
>> 44:     static final StackWalker INST = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
>> 45: 
> 
> Could `DROP_METHOD_INFO` also be used here?

yes but it's irrelevant in this benchmark as `getCallerClass` should be independent to `DROP_METHOD_INFO` option.  The implementation always drops method info in the implementation.  It does not affect the result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15642#discussion_r1323580483

From bchristi at openjdk.org  Tue Sep 12 21:34:52 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 12 Sep 2023 21:34:52 GMT
Subject: RFR: 8285447: StackWalker minimal batch size should be optimized
 for getCallerClass [v4]
In-Reply-To: 
References: <9GOajaNoxlTErKk8LdfrASj7G4Zm2AowG83U0cf2CjY=.ea62f090-34ed-486e-adf0-a4668b570644@github.com>
 <4tTHtnDKfaPHhUpYVq4RO-3SS2PcNrCPDSwillvAyA8=.323fed3c-5115-470d-989a-cbbdc99027c9@github.com>
 
 
Message-ID: 

On Tue, 12 Sep 2023 21:09:25 GMT, Mandy Chung  wrote:

>> test/micro/org/openjdk/bench/java/lang/CallerClassBench.java line 45:
>> 
>>> 43: public class CallerClassBench {
>>> 44:     static final StackWalker INST = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
>>> 45: 
>> 
>> Could `DROP_METHOD_INFO` also be used here?
>
> yes but it's irrelevant in this benchmark as `getCallerClass` should be independent to `DROP_METHOD_INFO` option.  The implementation always drops method info in the implementation.  It does not affect the result.

Ah - understood, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15642#discussion_r1323600936

From david.holmes at oracle.com  Tue Sep 12 21:44:37 2023
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Sep 2023 07:44:37 +1000
Subject: Java 21 clinit deadlock
In-Reply-To: 
References: 
 <77f901c7-5bb8-4703-8c64-b331913516b6@oracle.com>
 
 
Message-ID: 

Hi Simone,

Thanks for the logs. Unfortunately they shed no light on what is 
happening. There is no sign of the MutableHttpFields class starting 
actual initialization, though we can see that it was linked (verified). 
And there are no exceptions indicated relevant to the class loading and 
initialization process that I can discern.

The class initialization logging is unfortunately rather sparse and I 
think we would need to add some additional logging to shed further light 
on this. Are you in a position to patch the sources, create a custom 
build and test again with that build?

Cheers,
David

On 12/09/2023 6:35 pm, Simone Bordet wrote:
> David,
> 
> On Mon, Sep 11, 2023 at 9:29?AM Simone Bordet  wrote:
>>
>> Hi,
>>
>> On Mon, Sep 11, 2023 at 7:22?AM David Holmes  wrote:
>>> I've looked at the dump and there is no sign that the MutableHttpFields
>>> is actively in use. It suggests to me that class initialization has
>>> failed but the class state has not been correctly updated and the
>>> waiters released. There were some changes in JDK 21 about how failures
>>> in this area were handled, so it is possible I/we got something wrong.
>>> Is it possible to try running this with additional logging enabled e.g.
>>>
>>> -Xlog:class+init=debug -Xlog:exceptions=debug
>>
>> We will try this, than you!
> 
> Here is another failed run:
> JVM threads dump: https://gist.github.com/olamy/b3e20a76f0fc77232882b9be95db47e1
> JVM output (gist is truncated, download full file):
> https://gist.githubusercontent.com/olamy/86f0a1215c722e5e9acf96cae597422e/raw/4404693c39fd767122d34a7a3dde1d797afa6f25/gistfile1.txt
> 
> The JVM stops outputting at 2.360s, then we have a Jetty idle timeout
> after 30 seconds, then we see:
> 
> [51.472s][debug][exceptions] Thread::clear_pending_exception: cleared
> exception:java.lang.VirtualMachineError '.
> 
> And then more log lines follow after another 5 minutes.
> 
> Let us know your findings.
> 
> Thanks!
> 

From jlu at openjdk.org  Tue Sep 12 22:04:12 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Sep 2023 22:04:12 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
Message-ID: 

JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.

This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.

The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)

The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.

If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

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

Commit messages:
 - Update header / copyright for CurrencyFormat
 - Adjust CurrencyFormat test to read in .properties with UTF-8
 - Convert unicode escape sequences to native
 - Add clarifying comment in Bug6204853 for lack of conversion
 - Read JDK properties files in UTF-8 during build process for LRB

Changes: https://git.openjdk.org/jdk/pull/15694/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301991
  Stats: 28966 lines in 488 files changed: 14 ins; 0 del; 28952 mod
  Patch: https://git.openjdk.org/jdk/pull/15694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694

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

From duke at openjdk.org  Tue Sep 12 22:47:48 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 12 Sep 2023 22:47:48 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v15]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
Message-ID: 

On Tue, 12 Sep 2023 19:23:13 GMT, Roger Riggs  wrote:

>> ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - merge from master
>>  - Merge branch 'master' into optimization_for_uuid_to_string
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/util/UUID.java
>>    #	src/java.base/share/classes/jdk/internal/util/HexDigits.java
>>  - lo | hi => hi | lo
>>  - add DIGITS description
>>  - reversed how & hi
>>  - Merge branch 'master' into optimization_for_uuid_to_string
>>  - remove redundant parentheses
>>  - fix java doc, big-endian -> little-endian
>>  - Merge branch 'master' into optimization_for_uuid_to_string
>>  - use ByteArrayLittleEndian
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/e0845163...4f6ed3e6
>
> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 112:
> 
>> 110:                 | (DIGITS[b1 & 0xff] << 16)
>> 111:                 | (((long) DIGITS[b2 & 0xff]) << 32)
>> 112:                 | (((long) DIGITS[b3 & 0xff]) << 48);
> 
> Can you reverse the order of these source lines to put the shifts of the higher order bits before the lower order bit shifts.  `3333222211110000`. Its easier to understand where the bits end up in the long.
> The rest of the change is better focused.

if change packDigits order, performance will be slow, I don't know why yet.

The following is the data running on MacBookPro M1 Max :

make test TEST="micro:java.util.UUIDBench.toString"

Benchmark           (size)   Mode  Cnt   Score   Error   Units (current order)
UUIDBench.toString   20000  thrpt   15  96.396 ? 0.946  ops/us


Benchmark           (size)   Mode  Cnt   Score   Error   Units (change packDigits order)
UUIDBench.toString   20000  thrpt   15  86.496 ? 0.542  ops/us

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1323682688

From mik3hall at gmail.com  Tue Sep 12 22:50:26 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 12 Sep 2023 17:50:26 -0500
Subject: jpackage Windows Wix v4
Message-ID: <5C5EAAE4-8C12-4DAD-A6A0-7F1B56655015@gmail.com>

Curiosity. I was setting up a new Windows 10 VirtualBox image to do jpackage. It told me I needed Wix. First I needed dotnet to install wix. I then got a Wix v4. jpackage told me I needed candle.exe and light.exe from v3. I installed v3 but haven?t had a chance to try it. 

However, if v4 isn?t backward compatible with v3 how will jpackage continue to work with this? Or did I miss something in my v4 install? 

From redestad at openjdk.org  Tue Sep 12 22:56:49 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Sep 2023 22:56:49 GMT
Subject: RFR: 8315999: Improve Date toString performance [v9]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 
 
 
Message-ID: 

On Mon, 11 Sep 2023 16:13:01 GMT, ???  wrote:

>> It was a suggestion, implicitly paired with removing ` + (year < 0 ? 1 : 0)` from line 2188.
>
> The reason for not using off++ is that it can be executed out of order, which may result in better performance.

I don't think that would outweigh the extra branch and the increased code size. I'd opt for simplicity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323687644

From duke at openjdk.org  Tue Sep 12 23:00:27 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 12 Sep 2023 23:00:27 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v35]
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 incrementally with one additional commit since the last revision:

  Refactor stub handling to use a generic function for all types

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/c096ff62..ed8b95c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=33-34

  Stats: 178 lines in 8 files changed: 35 ins; 100 del; 43 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  Tue Sep 12 23:00:32 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 12 Sep 2023 23:00:32 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v34]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 11 Sep 2023 18:17:41 GMT, Jatin Bhateja  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix regression when intrinsics are disabled; enable insertion sort in intrinsic, change library name to libsimdsort
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4205:
> 
>> 4203: 
>> 4204:       snprintf(ebuf_, sizeof(ebuf_), "avx512_sort_double");
>> 4205:       StubRoutines::_arraysort_double = (address)os::dll_lookup(libsimdsort, ebuf_);
> 
> Hi @vamsi-parasa , If we align these C++ stub entry points with java intrinsic entry points which accept an element class argument, it will significantly cleanup the code referring to these stub entry points. We can pass an extra int type flag to stubs based on which C++ implementation can appropriately call type specific leaf level routines.

Hello Jatin, the suggested refactoring change is incorporated in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1323688986

From jlu at openjdk.org  Tue Sep 12 23:02:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Sep 2023 23:02:50 GMT
Subject: Integrated: JDK-8315946: DecimalFormat and CompactNumberFormat do
 allow U+FFFE and U+FFFF in the pattern
In-Reply-To: 
References: 
Message-ID: <-LCCQaYsRQJCQRCMb7Z1uufSygujk4GEvzSOpbDFU_E=.3f80ca77-23cb-4ad3-a54f-48055d49d6cb@github.com>

On Fri, 8 Sep 2023 23:02:02 GMT, Justin Lu  wrote:

> Please review this change which adjusts the pattern syntax specification for the two classes to represent the actual behavior. That is, U+FFFE and U+FFFF are allowed in the suffix/prefix. (Additionally; 'Unicode' is dropped from the definitions, as a Java character is composed of Unicode code points).
> 
> See code below, no exception is thrown.
> 
> 
> String uFFFE = "\uFFFE";
> String uFFFF = "\uFFFF";
> var a = new DecimalFormat("prefixStart"+uFFFE+"0.00"+uFFFF+"SuffixEnd");
> a.format(1); // returns "prefixStart?1.00?SuffixEnd"
> var b = new CompactNumberFormat(a.toPattern(), a.getDecimalFormatSymbols(), new String[] {""});
> b.format(1); // returns "prefixStart?1?SuffixEnd"

This pull request has now been integrated.

Changeset: dde11551
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/dde11551e26dedd28168d2d4528e9dd66ed82999
Stats:     8 lines in 2 files changed: 2 ins; 0 del; 6 mod

8315946: DecimalFormat and CompactNumberFormat do allow U+FFFE and U+FFFF in the pattern

Reviewed-by: naoto

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

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

From liach at openjdk.org  Tue Sep 12 23:16:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Sep 2023 23:16:40 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: 
References: 
Message-ID: 

On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu  wrote:

> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
> 
> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
> 
> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
> 
> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
> 
> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 227:

> 225:         try (FileInputStream input = new FileInputStream(propertiesPath);
> 226:              // Read in JDK .properties files in UTF-8
> 227:              InputStreamReader streamReader = new InputStreamReader(input, StandardCharsets.UTF_8)

Can we just uses `Files.newBufferedReader(Path.of(propertiesPath))` instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1323716978

From redestad at openjdk.org  Tue Sep 12 23:37:43 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Sep 2023 23:37:43 GMT
Subject: RFR: 8315999: Improve Date toString performance [v9]
In-Reply-To: <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com>
Message-ID: 

On Tue, 12 Sep 2023 17:23:00 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge from master

I think there's still too much going on in this PR, and it should probably be split up into multiple PRs.

I think some of this is going a bit overboard. For starters I don't want to see us adding a 1000-element lookup table for "`DecimalDigits::digitTriple`" without significant evidence that that is worth it at application level. As has been pointed out elsewhere lookup tables are prone to look great on microbenchmarks but may behave poorly and even regress real world applications by competing for cache. Any further additions needs to be justified with a thorough examination and benchmarks that better simulate noisy real world applications.

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 77:

> 75: 
> 76:     static {
> 77:         int[] digits_k = new int[1000];

I'm very skeptical that adding a 1000 element lookup table for  is worthwhile. That's a lookup table that'd span many cache lines, with plenty of cache misses. And even _if_ it is to be considered it should be split out and considered in isolation from this PR.

What does the 2, 1 or 0 value you put in the lowest byte signify?

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

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15658#pullrequestreview-1623337467
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323702300

From redestad at openjdk.org  Tue Sep 12 23:37:45 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Sep 2023 23:37:45 GMT
Subject: RFR: 8315999: Improve Date toString performance [v9]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com>
 <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com>
 
Message-ID: <_59sQtS1Sb6t7Gypojek3b1O4KbFTmeNuE84GULI4Go=.cbe5946a-c43a-49bf-946d-5ed4600f08b6@github.com>

On Tue, 12 Sep 2023 13:10:42 GMT, ???  wrote:

>> Of course, the optimization of DateTimeFormatter is more general, and we can spend time doing it later. The format of toString is fixed, we can not use DateTimeFormatter.
>
>> Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here?
>> 
>> Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications.
> 
> I submitted an optimization for the commonly used format of DateTimeFormatter::format

Do you have a link to that PR? Is there an RFE filed for it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323705970

From redestad at openjdk.org  Tue Sep 12 23:58:45 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 12 Sep 2023 23:58:45 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v15]
In-Reply-To: 
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 
 
 
Message-ID: 

On Tue, 12 Sep 2023 22:44:35 GMT, ???  wrote:

>> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 112:
>> 
>>> 110:                 | (DIGITS[b1 & 0xff] << 16)
>>> 111:                 | (((long) DIGITS[b2 & 0xff]) << 32)
>>> 112:                 | (((long) DIGITS[b3 & 0xff]) << 48);
>> 
>> Can you reverse the order of these source lines to put the shifts of the higher order bits before the lower order bit shifts.  `3333222211110000`. Its easier to understand where the bits end up in the long.
>> The rest of the change is better focused.
>
> if reverse packDigits order, performance will be slow, I don't know why yet.
> 
> The following is the data running on MacBookPro M1 Max :
> 
> make test TEST="micro:java.util.UUIDBench.toString"
> 
> Benchmark           (size)   Mode  Cnt   Score   Error   Units (current order 4f6ed3e6)
> UUIDBench.toString   20000  thrpt   15  96.396 ? 0.946  ops/us
> 
> 
> Benchmark           (size)   Mode  Cnt   Score   Error   Units (reverse packDigits order)
> UUIDBench.toString   20000  thrpt   15  86.496 ? 0.542  ops/us

Looks like something that might be an interesting puzzler for JIT compiler folks. Perhaps added implicit casts to long messes something up?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14745#discussion_r1323773899

From duke at openjdk.org  Wed Sep 13 01:15:38 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 01:15:38 GMT
Subject: RFR: 8315999: Improve Date toString performance [v10]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

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

  remove DIGITS_K

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/e4c5b67b..8c76799c

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

  Stats: 59 lines in 2 files changed: 6 ins; 38 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/15658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15658/head:pull/15658

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

From duke at openjdk.org  Wed Sep 13 01:15:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 01:15:41 GMT
Subject: RFR: 8315999: Improve Date toString performance [v9]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com>
 
Message-ID: <-Hqle78z33az2yUm0LBqSYw_P7pisqWDt0afZc2xY_M=.97b412fd-f5f5-4032-9e65-9820a3963888@github.com>

On Tue, 12 Sep 2023 23:08:25 GMT, Claes Redestad  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merge from master
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 77:
> 
>> 75: 
>> 76:     static {
>> 77:         int[] digits_k = new int[1000];
> 
> I'm very skeptical that adding a 1000 element lookup table for  is worthwhile. That's a lookup table that'd span many cache lines, with plenty of cache misses. And even _if_ it is to be considered it should be split out and considered in isolation from this PR.
> 
> What does the 2, 1 or 0 value you put in the lowest byte signify?

DIGITS_K has been removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323808508

From duke at openjdk.org  Wed Sep 13 01:19:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 01:19:42 GMT
Subject: RFR: 8315999: Improve Date toString performance [v10]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: <4D-jfiuQtZ_VtVl1kzOT7W8XbwymgugJZQb58L54riY=.60f8ba07-2981-4422-8f26-64696b2bdbeb@github.com>

On Wed, 13 Sep 2023 01:15:38 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove DIGITS_K

> Do you have a link to that PR? Is there an RFE filed for it?

@cl4es  Optimization of DateTimeFormatter::format should be another PR, I created a [branche](https://github.com/wenshao/jdk/tree/optim_for_datetime_format) but the work is unfinished.

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1716790719

From duke at openjdk.org  Wed Sep 13 01:19:46 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 01:19:46 GMT
Subject: RFR: 8315999: Improve Date toString performance [v9]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 <2_A4KtrgFdI3lDQAKnqfwAu4bvbZdh8tRqmQz2nkALQ=.6b956af6-0fe1-4139-8b78-ce1af5b24b6c@github.com>
 
Message-ID: 

On Tue, 12 Sep 2023 17:53:47 GMT, ExE Boss  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merge from master
>
> src/java.base/share/classes/java/time/LocalTime.java line 141:
> 
>> 139:     @Stable
>> 140:     static final int[] DIGITS_K = new int[1000];
>> 141: 
> 
> Suggestion:

DIGITS_K has been removed

> src/java.base/share/classes/java/time/LocalTime.java line 179:
> 
>> 177:             int c3 = i % 10 + '0';
>> 178:             DIGITS_K[i] = c0 + (c1 << 8) + (c2 << 16) + (c3 << 24);
>> 179:         }
> 
> Suggestion:

DIGITS_K has been removed

> src/java.base/share/classes/java/time/LocalTime.java line 1724:
> 
>> 1722:             v = DIGITS_K[rem2];
>> 1723:         } else {
>> 1724:             v = DIGITS_K[div - div2 * 1000];
> 
> Suggestion:
> 
>             v = DecimalDigits.digitTriple(div - div2 * 1000);

DIGITS_K has been removed

> src/java.base/share/classes/java/time/LocalTime.java line 1740:
> 
>> 1738:                     buf,
>> 1739:                     off,
>> 1740:                     DIGITS_K[rem1] & 0xffffff00 | (v >> 24)
> 
> Suggestion:
> 
>                     DecimalDigits.digitTriple(rem1) & 0xffffff00 | (v >> 24)

DIGITS_K has been removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323811383
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323811309
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323811510
PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323811428

From mchung at openjdk.org  Wed Sep 13 01:20:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 13 Sep 2023 01:20:22 GMT
Subject: RFR: 8267509: Improve IllegalAccessException message to include the
 cause of the exception
Message-ID: <8Ka-IY9mMbtFNWGAr5h-etSp-1WFkeaC4kJP_zO_KGg=.c9aaf508-c6c1-4b65-bc07-2c889cc4c578@github.com>

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`.

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

Commit messages:
 - 8267509: Improve IllegalAccessException message to include the cause of the exception

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

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

From duke at openjdk.org  Wed Sep 13 01:45:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 01:45:13 GMT
Subject: RFR: 8316150: Refactor get chars and string size
Message-ID: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@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:
 - move StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1
 - move *::stringSize to jdk.internal.util.DecimalDigits::stringSize

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: 374 lines in 9 files changed: 153 ins; 190 del; 31 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 duke at openjdk.org  Wed Sep 13 02:11:20 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 02:11:20 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v2]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: <2qbgiUTpdAgK7e2-KyDJLDo89Q0-Ogq27_P6ccQ4lgY=.38492181-6835-44ca-9d60-b0a07533a203@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

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

  fix build error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/f553fb16..1ab86e2a

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Wed Sep 13 02:17:00 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 02:17:00 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v3]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

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

  fix build error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/1ab86e2a..fe5263c3

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Wed Sep 13 02:48:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 02:48:17 GMT
Subject: RFR: 8315999: Improve Date toString performance [v11]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

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

  restore ZoneOffset::buildId, reduce changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/8c76799c..8471814c

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

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

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

From duke at openjdk.org  Wed Sep 13 02:54:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 02:54:09 GMT
Subject: RFR: 8315999: Improve Date toString performance [v12]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

??? has updated the pull request incrementally with two additional commits since the last revision:

 - restore ZoneOffset::buildId, reduce changes
 - restore ZoneOffset::buildId, reduce changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/8471814c..d3ad4906

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

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

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

From duke at openjdk.org  Wed Sep 13 02:54:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 02:54:09 GMT
Subject: RFR: 8315999: Improve Date toString performance [v12]
In-Reply-To: <_59sQtS1Sb6t7Gypojek3b1O4KbFTmeNuE84GULI4Go=.cbe5946a-c43a-49bf-946d-5ed4600f08b6@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 <5uVaoPMZn4rINB1CzLMhxKD1iqkjzNHAcxzyFvsDbu4=.2d7da66b-903d-441d-b1f5-00811284b986@github.com>
 <6XupIICeOBSLSNFkbSGNYBwIKtfJ68Y4gtZ3LdSDO50=.96a97dcf-3a1b-4cd6-aefe-da3ef2d5b15c@github.com>
 
 <_59sQtS1Sb6t7Gypojek3b1O4KbFTmeNuE84GULI4Go=.cbe5946a-c43a-49bf-946d-5ed4600f08b6@github.com>
Message-ID: 

On Tue, 12 Sep 2023 23:10:43 GMT, Claes Redestad  wrote:

>>> Have you considered potentially more generalizable optimizations to `DateTimeFormatter.ISO_INSTANT.format(this)` here?
>>> 
>>> Hand-rolling a fixed-length buffer, skipping the `StringBuilder` .. understandably this can have a performance edge, but perhaps a `DateTimeFormatter` like `ISO_INSTANT` can be optimized to get closer to whatever speed-up this gets you - with broader implications.
>> 
>> I submitted an optimization for the commonly used format of DateTimeFormatter::format
>
> Do you have a link to that PR? Is there an RFE filed for it?

Optimization of DateTimeFormatter::format should be another PR, I created a [branche](https://github.com/wenshao/jdk/tree/optim_for_datetime_format) but the work is unfinished.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1323870413

From liach at openjdk.org  Wed Sep 13 05:11:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Sep 2023 05:11:37 GMT
Subject: RFR: 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 increase the exception message thrown by asVarargsCollector`.

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1722:

> 1720:             return this.withVarargs(true);
> 1721:         } catch (IllegalArgumentException ex) {
> 1722:             throw new IllegalAccessException("cannot make variable arity: " + this + " because " + ex.getMessage());

This now drops the member information (owner and name) from the message. Is that intended?

In addition, the original message appears to include the method type, which can be used to diagnose why varargs is not possible (not an array for trailing parameter). I fail to see what extra information this patch offers that actually makes debugging easier as claimed in the JBS issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15698#discussion_r1323975225

From liach at openjdk.org  Wed Sep 13 05:12:46 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Sep 2023 05:12:46 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v3]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Wed, 13 Sep 2023 02:17:00 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build error

Changes requested by liach (Author).

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 Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1323970440

From simone.bordet at gmail.com  Wed Sep 13 06:16:32 2023
From: simone.bordet at gmail.com (Simone Bordet)
Date: Wed, 13 Sep 2023 08:16:32 +0200
Subject: Java 21 clinit deadlock
In-Reply-To: 
References: 
 <77f901c7-5bb8-4703-8c64-b331913516b6@oracle.com>
 
 
 
Message-ID: 

Hi,

On Tue, Sep 12, 2023 at 11:44?PM David Holmes  wrote:
>
> Hi Simone,
>
> Thanks for the logs. Unfortunately they shed no light on what is
> happening. There is no sign of the MutableHttpFields class starting
> actual initialization, though we can see that it was linked (verified).
> And there are no exceptions indicated relevant to the class loading and
> initialization process that I can discern.
>
> The class initialization logging is unfortunately rather sparse and I
> think we would need to add some additional logging to shed further light
> on this. Are you in a position to patch the sources, create a custom
> build and test again with that build?

Yes we can do this.

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From duke at openjdk.org  Wed Sep 13 08:28:57 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 08:28:57 GMT
Subject: Integrated: 8311207: Cleanup for Optimization for UUID.toString
In-Reply-To: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
Message-ID: 

On Sat, 1 Jul 2023 01:44:15 GMT, ???  wrote:

> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.util.UUIDBench.toString"
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
> 
> 
> 
> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * cpu : aliyun yitian 710 (aarch64)
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
> 
> 
> ## 4. MacBookPro M1 Pro
> ``` diff
> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
> 
> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
> 
> 
> ## 5. Orange Pi 5 Plus
> 
> ``` diff
> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
> 
> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)

This pull request has now been integrated.

Changeset: f8df754b
Author:    shaojin.wensj 
Committer: Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/f8df754b9a3f58ff5f26e63de70d02f3433a9384
Stats:     55 lines in 2 files changed: 5 ins; 12 del; 38 mod

8311207: Cleanup for Optimization for UUID.toString

Reviewed-by: liach, rriggs

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

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

From duke at openjdk.org  Wed Sep 13 12:27:39 2023
From: duke at openjdk.org (Soumadipta Roy)
Date: Wed, 13 Sep 2023 12:27:39 GMT
Subject: RFR: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java [v3]
In-Reply-To: 
References: 
Message-ID: 

> This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations:
> 
> * before                           : **200.64s user 20.94s system 204% cpu 1:48.47 total**
> * fully parallel                  : **308.84s user 23.75s system 479% cpu 1:09.42 total**
> * default-details-tck       : **244.69s user 22.03s system 314% cpu 1:24.94 total**
> * default-fjp_details-others : **260.12s user 24.47s system 404% cpu 1:10.31 total**
> 
> Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination.

Soumadipta Roy has updated the pull request incrementally with one additional commit since the last revision:

  Adding summary for each parallelized section.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15619/files
  - new: https://git.openjdk.org/jdk/pull/15619/files/1482259c..12e1a02a

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

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

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

From duke at openjdk.org  Wed Sep 13 12:27:57 2023
From: duke at openjdk.org (Soumadipta Roy)
Date: Wed, 13 Sep 2023 12:27:57 GMT
Subject: RFR: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 7 Sep 2023 16:08:16 GMT, Martin Buchholz  wrote:

> Hello Soumadipta - pleased to "meet" you.
> 
> If the intent is to split the tests into relatively more and less important variants for placing into separate tiers, that should be clear from the @summary's in the tests.

Hi @Martin-Buchholz the latest commit addresses the comment regarding missing summary for each section of tests. Also from the JBS bug, I can see it has been agreed to have a separate PR for improvements to the test itself and segregation into appropriate tiers.

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

PR Comment: https://git.openjdk.org/jdk/pull/15619#issuecomment-1717526009

From coffeys at openjdk.org  Wed Sep 13 12:45:57 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 13 Sep 2023 12:45:57 GMT
Subject: RFR: 8316087: Test SignedLoggerFinderTest.java is still failing
Message-ID: <_Vglr1cuPaLOyi_efcPRaOvjGkPLyCiTqcdqSZXl5qY=.749e730f-53e3-43ac-a5d5-e6b80680bb40@github.com>

Some log messages from the test may be dropped if the bootstraplogger is in use at time of log call. (bootstap logger logs at INFO level, the security event logger logs at DEBUG level)

Modify the test to use a patched EventHelper class to let it log at INFO level also, ensuring the bootstrap logger handles such logs.

I'll log a follow on enhancement where the default logging level for bootstrap logger can be modified (perhaps via the existing `jdk.system.logger.level` system property)

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

Commit messages:
 - More whitespace
 - Whitespace correction
 - 8316087

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

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

From prappo at openjdk.org  Wed Sep 13 12:46:02 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 13 Sep 2023 12:46:02 GMT
Subject: RFR: 8316187: Modernize an example in StringTokenizer
Message-ID: 

This modernizes an example to use the extended for-statement introduced in JDK 1.5.

I understand that StringTokenizer is a legacy class. But legacy or not, a class shouldn't promote older constructs when newer fit better. Especially when advising on preferred alternatives to itself.

That said, I wouldn't go as far as to use `var` anywhere in that example: JDK 10, which introduced `var`, might still be relatively new to some. Nor would I inline the call to `String.split` in the for-statement to dispense with the `String[] result` variable: I reckon it's good for a reader unfamiliar with `String.split` to see the type it returns.

Perhaps one additional thing to ponder is this: we could either add `@see` to point to `String.split` or make the whole example a `@snippet`, which `@link`s code to the definition of `String.split`.

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

Commit messages:
 - Initial commit

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

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

From pminborg at openjdk.org  Wed Sep 13 12:51:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Sep 2023 12:51:19 GMT
Subject: RFR: 8316050: Use hexadecimal encoding in MemorySegment::toString
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use hexadecimal representation for a memory segment address rather than a decimal one.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Change from limit to byteSize in MS::toString

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15670/files
  - new: https://git.openjdk.org/jdk/pull/15670/files/ed5c76c9..0a021318

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

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

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

From pminborg at openjdk.org  Wed Sep 13 12:51:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Sep 2023 12:51:19 GMT
Subject: Integrated: 8316050: Use hexadecimal encoding in
 MemorySegment::toString
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 21:17:27 GMT, Per Minborg  wrote:

> This PR proposes to use hexadecimal representation for a memory segment address rather than a decimal one.

This pull request has now been integrated.

Changeset: f9ab115a
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/f9ab115acb5044f25e2553521a09c35ae02c9b84
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8316050: Use hexadecimal encoding in MemorySegment::toString

Reviewed-by: rriggs, mcimadamore

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

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

From dl at openjdk.org  Wed Sep 13 12:54:23 2023
From: dl at openjdk.org (Doug Lea)
Date: Wed, 13 Sep 2023 12:54:23 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v31]
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:

  Strengthen translation of getAndX atomics; revert or adapt FJP accordingly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/729e34f6..e8d7b75f

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

  Stats: 130 lines in 2 files changed: 22 ins; 19 del; 89 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  Wed Sep 13 14:08:15 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 14:08:15 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v4]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

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

  add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/fe5263c3..1ef45c5f

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 duke at openjdk.org  Wed Sep 13 14:08:16 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 14:08:16 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v3]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: <-G2c-fzLIlHQduEcYW29y5GjRbRFq5w0Gttg8WG_oHc=.40a10aaa-8060-42ec-8b81-f18c60e1cc59@github.com>

On Wed, 13 Sep 2023 02:17:00 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build error

@cl4es can you help me to review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1717697947

From duke at openjdk.org  Wed Sep 13 14:22:35 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 14:22:35 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
Message-ID: 

> improve date toString performance, includes:
> 
> java.util.Date.toString
> java.util.Date.toGMTString
> java.time.Instant.toString
> java.time.LocalDate.toString
> java.time.LocalDateTime.toString
> java.time.LocalTime.toString

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

  simplify LocalDate::getChars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15658/files
  - new: https://git.openjdk.org/jdk/pull/15658/files/d3ad4906..b7a3528c

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

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

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

From duke at openjdk.org  Wed Sep 13 14:22:36 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 14:22:36 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 
 
 
 
Message-ID: 

On Tue, 12 Sep 2023 22:53:34 GMT, Claes Redestad  wrote:

>> The reason for not using off++ is that it can be executed out of order, which may result in better performance.
>
> I don't think that would outweigh the extra branch and the increased code size. I'd opt for simplicity.

I've simplified LocalDate::getChars based on your suggestion

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15658#discussion_r1324587746

From dfuchs at openjdk.org  Wed Sep 13 14:49:40 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 13 Sep 2023 14:49:40 GMT
Subject: RFR: 8316087: Test SignedLoggerFinderTest.java is still failing
In-Reply-To: <_Vglr1cuPaLOyi_efcPRaOvjGkPLyCiTqcdqSZXl5qY=.749e730f-53e3-43ac-a5d5-e6b80680bb40@github.com>
References: <_Vglr1cuPaLOyi_efcPRaOvjGkPLyCiTqcdqSZXl5qY=.749e730f-53e3-43ac-a5d5-e6b80680bb40@github.com>
Message-ID: <800F8fCtXV3a3keRVPMp69NX_d5IMfcWXWHylXUT_CE=.2756970c-d38c-4414-ba93-5b2bf5acf229@github.com>

On Wed, 13 Sep 2023 11:26:30 GMT, Sean Coffey  wrote:

> Some log messages from the test may be dropped if the bootstraplogger is in use at time of log call. (bootstap logger logs at INFO level, the security event logger logs at DEBUG level)
> 
> Modify the test to use a patched EventHelper class to let it log at INFO level also, ensuring the bootstrap logger handles such logs.
> 
> I'll log a follow on enhancement where the default logging level for bootstrap logger can be modified (perhaps via the existing `jdk.system.logger.level` system property)

Looks fine to me as a shorter term solution until the enhancement is done. An alternative enhancement could be to have another system property to configure at which level the EventHelper should log.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15711#pullrequestreview-1624746847

From coffeys at openjdk.org  Wed Sep 13 15:08:53 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 13 Sep 2023 15:08:53 GMT
Subject: Integrated: 8316087: Test SignedLoggerFinderTest.java is still failing
In-Reply-To: <_Vglr1cuPaLOyi_efcPRaOvjGkPLyCiTqcdqSZXl5qY=.749e730f-53e3-43ac-a5d5-e6b80680bb40@github.com>
References: <_Vglr1cuPaLOyi_efcPRaOvjGkPLyCiTqcdqSZXl5qY=.749e730f-53e3-43ac-a5d5-e6b80680bb40@github.com>
Message-ID: <-AiFGuXpMGOVC6WLg-MHZrPyAAAnfjZeoGQtcfC6F0M=.c5eef8bf-d3dd-4678-8c49-4a024769238f@github.com>

On Wed, 13 Sep 2023 11:26:30 GMT, Sean Coffey  wrote:

> Some log messages from the test may be dropped if the bootstraplogger is in use at time of log call. (bootstap logger logs at INFO level, the security event logger logs at DEBUG level)
> 
> Modify the test to use a patched EventHelper class to let it log at INFO level also, ensuring the bootstrap logger handles such logs.
> 
> I'll log a follow on enhancement where the default logging level for bootstrap logger can be modified (perhaps via the existing `jdk.system.logger.level` system property)

This pull request has now been integrated.

Changeset: ff240a91
Author:    Sean Coffey 
URL:       https://git.openjdk.org/jdk/commit/ff240a9135e0f0c78ecffadbef38edb3b0479653
Stats:     15 lines in 2 files changed: 9 ins; 3 del; 3 mod

8316087: Test SignedLoggerFinderTest.java is still failing

Reviewed-by: dfuchs

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

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

From prappo at openjdk.org  Wed Sep 13 15:52:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 13 Sep 2023 15:52:07 GMT
Subject: RFR: 8316207: Fix typos in java.io.StreamTokenizer
Message-ID: <6x1Hpv-9vQ5hyP6KSDcFEshLeWKpT0BaVyw_HnlusYk=.28bb20b8-2c84-4218-b2f3-2a31196a31cb@github.com>

This is a simple PR to fix a few typos in the doc comments of java.io.StreamTokenizer. When reviewing it, please double-check my proposal for L481. For this, you should ideally read the complete comment to the `lowerCaseMode` method. Thanks!

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

Commit messages:
 - Initial commit

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

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

From dl at openjdk.org  Wed Sep 13 16:19:36 2023
From: dl at openjdk.org (Doug Lea)
Date: Wed, 13 Sep 2023 16:19:36 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v32]
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 77 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Strengthen translation of getAndX atomics; revert or adapt FJP accordingly
 - Merge branch 'openjdk:master' into JDK-8288899
 - Force more orderings; improve diagnostics
 - Simplify signalling
 - Always help terminate when stopping
 - Merge branch 'openjdk:master' into JDK-8288899
 - Use non-recursive tasks in close tests
 - Allow ThreadGroup access in tck tests
 - Avoid needing test threads
 - ... and 67 more: https://git.openjdk.org/jdk/compare/35251845...d04ce80f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/e8d7b75f..d04ce80f

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

  Stats: 5410 lines in 768 files changed: 2649 ins; 1894 del; 867 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 mchung at openjdk.org  Wed Sep 13 16:21:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 13 Sep 2023 16:21:14 GMT
Subject: RFR: 8267509: Improve IllegalAccessException message to include
 the cause of the exception [v2]
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: 

> 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`.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  use member (not method handle)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15698/files
  - new: https://git.openjdk.org/jdk/pull/15698/files/8d5f1b16..921f1397

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

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

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

From mchung at openjdk.org  Wed Sep 13 16:34:41 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 13 Sep 2023 16:34:41 GMT
Subject: RFR: 8267509: Improve IllegalAccessException message to include
 the cause of the exception [v2]
In-Reply-To: 
References: <8Ka-IY9mMbtFNWGAr5h-etSp-1WFkeaC4kJP_zO_KGg=.c9aaf508-c6c1-4b65-bc07-2c889cc4c578@github.com>
 
Message-ID: 

On Wed, 13 Sep 2023 05:08:58 GMT, Chen Liang  wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use member (not method handle)
>
> src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1722:
> 
>> 1720:             return this.withVarargs(true);
>> 1721:         } catch (IllegalArgumentException ex) {
>> 1722:             throw new IllegalAccessException("cannot make variable arity: " + this + " because " + ex.getMessage());
> 
> This now drops the member information (owner and name) from the message. Is that intended?
> 
> In addition, the original message appears to include the method type, which can be used to diagnose why varargs is not possible (not an array for trailing parameter). I fail to see what extra information this patch offers that actually makes debugging easier as claimed in the JBS issue.

Good catch.  It's not intended.  Fixed.

I think in general it would be useful to make it clear in the exception message of the reason especially for those who are new in using method handles.  Looking it again, it can simply hardcode the message (more friendly than IAE exception message):


java.lang.IllegalAccessException: cannot make variable arity: MyClass.m(Object[],int)void/invokeStatic because not an array type: int

vs

java.lang.IllegalAccessException: cannot make variable arity: trailing parameter type is not an array type: MyClass.m(Object[],int)void/invokeStatic

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15698#discussion_r1324780782

From duke at openjdk.org  Wed Sep 13 17:29:41 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Wed, 13 Sep 2023 17:29:41 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Aug 2023 20:23:13 GMT, Aleksey Shipilev  wrote:

>> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
>> 
>> final int size = (1 << 30) + 1;
>> final List list = new ArrayList<>(size);
>> for (int i = 0; i < size; ++i)
>>     list.add((byte) 0);
>> Collections.rotate(list, size - 1);
>> 
>> Output:
>> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
>> 
>> In that case private method `Collections.rotate1` will be called. And the line:
>> `i += distance;`
>> will cause overflow. I fixed this method and wrote a test for it.
>> 
>> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
>> 
>> Kindly ask you to raise a bug.
>
> Submitted: [JDK-8314236](https://bugs.openjdk.org/browse/JDK-8314236)
> 
> Please change the PR synopsis to: "8314236: Overflow in Collections.rotate".
> 
> Also go to https://github.com/nikita-sakharin/jdk/actions, and enable testing workflows.

Aleksey Shipil?v (@shipilev), kindly remind you about the PR.

Could I ask you to review it, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/15270#issuecomment-1718034420

From jlu at openjdk.org  Wed Sep 13 17:38:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 17:38:28 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: 
References: 
Message-ID: 

> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
> 
> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
> 
> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
> 
> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
> 
> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

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

  Replace InputStreamReader with BufferedReader

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15694/files
  - new: https://git.openjdk.org/jdk/pull/15694/files/0f3698a5..ceb48bbe

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

  Stats: 18 lines in 2 files changed: 6 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694

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

From mchung at openjdk.org  Wed Sep 13 17:52:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 13 Sep 2023 17:52:22 GMT
Subject: RFR: 8267509: Improve IllegalAccessException message to include
 the cause of the exception [v3]
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: <_dK6ECQnlvrIg7rV9NGI6HK4p8fr5L_AQsyDSUJw0G8=.9a08ea49-ef5c-4355-a892-03b083180b58@github.com>

> 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`.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  revised message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15698/files
  - new: https://git.openjdk.org/jdk/pull/15698/files/921f1397..9cdd1f32

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

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

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

From jlu at openjdk.org  Wed Sep 13 18:00:04 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 18:00:04 GMT
Subject: RFR: 8313813: Field sun.util.calendar.CalendarDate#forceStandardTime
 is never set
Message-ID: 

Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.

`forceStandardTime` is always false.

In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.

As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Wed Sep 13 18:14:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Sep 2023 18:14:41 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu  wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15694#pullrequestreview-1625154951

From aturbanov at openjdk.org  Wed Sep 13 18:22:42 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Sep 2023 18:22:42 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 17:52:13 GMT, Justin Lu  wrote:

> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
> 
> `forceStandardTime` is always false.
> 
> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
> 
> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.

src/java.base/share/classes/sun/util/calendar/CalendarDate.java line 293:

> 291: 
> 292: 
> 293:     public boolean isStandardTime() {

Can we remove(inline) this method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1324902104

From mchung at openjdk.org  Wed Sep 13 18:40:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 13 Sep 2023 18:40:07 GMT
Subject: RFR: 8315810: Reimplement
 sun.reflect.ReflectionFactory::newConstructorForSerialization with method
 handles [v3]
In-Reply-To: 
References: 
Message-ID: 

> This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles.
> 
> This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization.  This change will allow such VM hack to be removed.
> 
> A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue.   I expect this change has very low compatibility risk.   This system property is undocumented and will be removed in a future release.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15600/files
  - new: https://git.openjdk.org/jdk/pull/15600/files/fb3bf590..c4e39d12

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

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

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

From jlu at openjdk.org  Wed Sep 13 18:41:12 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 18:41:12 GMT
Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for
 j.text.Format classes [v5]
In-Reply-To: 
References: 
Message-ID: 

> 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`).

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

  Adjust spec to not spec ALL, prevent potential maintenance/peformance issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15459/files
  - new: https://git.openjdk.org/jdk/pull/15459/files/0b0aeb51..6fe64f17

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

  Stats: 13 lines in 4 files changed: 0 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15459.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15459/head:pull/15459

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

From jlu at openjdk.org  Wed Sep 13 18:46:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 18:46:38 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 13 Sep 2023 18:12:15 GMT, Naoto Sato  wrote:

> Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion.

Thanks for the review; (In addition to testing), I ran a script to verify only white space escape sequences exist in JDK .properties files. (Excluding escape sequences in test files that should remain as is for the purpose of the test)

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-1718139807

From rriggs at openjdk.org  Wed Sep 13 18:49:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Sep 2023 18:49:40 GMT
Subject: RFR: 8315810: Reimplement
 sun.reflect.ReflectionFactory::newConstructorForSerialization with method
 handles [v3]
In-Reply-To: 
References: 
 
Message-ID: <9kp6QLT60eNmtFBxgzkXvHbf5G9rVXPjSAflMqXdfqI=.add781d8-ad29-48bb-83ab-31118bd3c85a@github.com>

On Wed, 13 Sep 2023 18:40:07 GMT, Mandy Chung  wrote:

>> This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles.
>> 
>> This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization.  This change will allow such VM hack to be removed.
>> 
>> A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue.   I expect this change has very low compatibility risk.   This system property is undocumented and will be removed in a future release.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15600#pullrequestreview-1625212661

From rriggs at openjdk.org  Wed Sep 13 19:05:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Sep 2023 19:05:48 GMT
Subject: RFR: 8316050: Use hexadecimal encoding in MemorySegment::toString
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 12:51:19 GMT, Per Minborg  wrote:

>> This PR proposes to use hexadecimal representation for a memory segment address rather than a decimal one.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change from limit to byteSize in MS::toString

Making changes after commits are approved suggests that additional time should be allowed to the approvers to re-check.

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

PR Comment: https://git.openjdk.org/jdk/pull/15670#issuecomment-1718165093

From alexey.semenyuk at oracle.com  Wed Sep 13 19:21:51 2023
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 13 Sep 2023 15:21:51 -0400
Subject: jpackage Windows Wix v4
In-Reply-To: <5C5EAAE4-8C12-4DAD-A6A0-7F1B56655015@gmail.com>
References: <5C5EAAE4-8C12-4DAD-A6A0-7F1B56655015@gmail.com>
Message-ID: 

jpoackage requires at least Wix v3.0. If it doesn't recognize Wix4, it 
is a bug.

- Alexey

On 9/12/2023 6:50 PM, Michael Hall wrote:
> Curiosity. I was setting up a new Windows 10 VirtualBox image to do jpackage. It told me I needed Wix. First I needed dotnet to install wix. I then got a Wix v4. jpackage told me I needed candle.exe and light.exe from v3. I installed v3 but haven?t had a chance to try it.
>
> However, if v4 isn?t backward compatible with v3 how will jpackage continue to work with this? Or did I miss something in my v4 install?


From rriggs at openjdk.org  Wed Sep 13 19:24:46 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Sep 2023 19:24:46 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: 

On Wed, 13 Sep 2023 14:22:35 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify LocalDate::getChars

Based on the use cases cited, if your library needs specific performance improvements for specific formats, they should be done in that library.

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718186604

From mik3hall at gmail.com  Wed Sep 13 19:27:13 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 13 Sep 2023 14:27:13 -0500
Subject: jpackage Windows Wix v4
In-Reply-To: 
References: <5C5EAAE4-8C12-4DAD-A6A0-7F1B56655015@gmail.com>
 
Message-ID: <838E23B7-2247-4674-A60C-500A0BECE5F9@gmail.com>



> On Sep 13, 2023, at 2:21 PM, Alexey Semenyuk  wrote:
> 
> jpoackage requires at least Wix v3.0. If it doesn't recognize Wix4, it is a bug.
> 
> - Alexey
> 
> On 9/12/2023 6:50 PM, Michael Hall wrote:
>> Curiosity. I was setting up a new Windows 10 VirtualBox image to do jpackage. It told me I needed Wix. First I needed dotnet to install wix. I then got a Wix v4. jpackage told me I needed candle.exe and light.exe from v3. I installed v3 but haven?t had a chance to try it.
>> 
>> However, if v4 isn?t backward compatible with v3 how will jpackage continue to work with this? Or did I miss something in my v4 install?
> 

Wix 4 looks pretty different was my concern. The dotnet install put into my user directory in a .dotnet directory. .dotnet\tool\wix or something pretty close to that. I had to add that to path. There didn?t appear to be any accompanying candle or light exe?s that jpackage seemed to expect. Assuming you are going to sometime have to support Wix v4 it might be worth looking at.  

From rriggs at openjdk.org  Wed Sep 13 19:28:46 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Sep 2023 19:28:46 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: 

On Wed, 13 Sep 2023 14:22:35 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify LocalDate::getChars

As a consideration to core-libs-dev readers, push commits when you are convinced are ready for review and you don't intend to make more changes. It will improve the signal to noise ratio.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718192179

From mik3hall at gmail.com  Wed Sep 13 19:37:37 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 13 Sep 2023 14:37:37 -0500
Subject: jpackage Windows Wix v4
In-Reply-To: <838E23B7-2247-4674-A60C-500A0BECE5F9@gmail.com>
References: <5C5EAAE4-8C12-4DAD-A6A0-7F1B56655015@gmail.com>
 
 <838E23B7-2247-4674-A60C-500A0BECE5F9@gmail.com>
Message-ID: <27B2FA68-F977-4967-9A6D-299ADBDE0576@gmail.com>



> On Sep 13, 2023, at 2:27 PM, Michael Hall  wrote:
> 
> 
> 
>> On Sep 13, 2023, at 2:21 PM, Alexey Semenyuk  wrote:
>> 
>> jpoackage requires at least Wix v3.0. If it doesn't recognize Wix4, it is a bug.
>> 
>> - Alexey
>> 
>> On 9/12/2023 6:50 PM, Michael Hall wrote:
>>> Curiosity. I was setting up a new Windows 10 VirtualBox image to do jpackage. It told me I needed Wix. First I needed dotnet to install wix. I then got a Wix v4. jpackage told me I needed candle.exe and light.exe from v3. I installed v3 but haven?t had a chance to try it.
>>> 
>>> However, if v4 isn?t backward compatible with v3 how will jpackage continue to work with this? Or did I miss something in my v4 install?
>> 
> 
> Wix 4 looks pretty different was my concern. The dotnet install put into my user directory in a .dotnet directory. .dotnet\tool\wix or something pretty close to that. I had to add that to path. There didn?t appear to be any accompanying candle or light exe?s that jpackage seemed to expect. Assuming you are going to sometime have to support Wix v4 it might be worth looking at.  

Again, possibly there is some other, more complete, way to get Wix v4 that I missed that would be compatible with jpackage going forward. I?m not remembering exactly what led my do getting v4. Possibly it?s not even GA yet?


From jlu at openjdk.org  Wed Sep 13 19:46:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 19:46:08 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
> 
> `forceStandardTime` is always false.
> 
> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
> 
> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.

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

  Remove isStandardTime() and inline as false

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15726/files
  - new: https://git.openjdk.org/jdk/pull/15726/files/d31bafae..91bd5a3f

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

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

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

From jlu at openjdk.org  Wed Sep 13 19:46:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 19:46:08 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v2]
In-Reply-To: 
References: 
 
Message-ID: <6GDuNc9EOcZ60JnQslsrm1qqMXDnicHSuNXXsQG1-ls=.0976163e-c7a6-4afd-a995-8fcaddae6cb2@github.com>

On Wed, 13 Sep 2023 19:40:04 GMT, Justin Lu  wrote:

>> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
>> 
>> `forceStandardTime` is always false.
>> 
>> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
>> 
>> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove isStandardTime() and inline as false

src/java.base/share/classes/sun/util/calendar/AbstractCalendar.java line 170:

> 168:             // adjust time zone and daylight saving
> 169:             int[] offsets = new int[2];
> 170:             if (date.isStandardTime()) {

This seems a little suspicious considering `isStandardTime()` is always false.

However, at this point, there shouldn't be any behavioral changes probably.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1324987799

From duke at openjdk.org  Wed Sep 13 19:48:46 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 13 Sep 2023 19:48:46 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v21]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 12 Sep 2023 10:49:38 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 two additional commits since the last revision:
> 
>  - add missing space + reflow lines
>  - Fix typo
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java line 311:

> 309:         };
> 310: 
> 311:         CANONICAL_LAYOUTS = Map.ofEntries(

`LibFallback::wcharSize()` and?other?getters for?`LibFallback.NativeConstants`?fields can?throw an?error when?`LibFallback.SUPPORTED` is?`false` due?to the?`fallbackLinker`?library not?being?present, so?this static?initializer should?be?made into?a?method?instead:
Suggestion:

    static final Map CANONICAL_LAYOUTS = initCanonicalLayouts();

    private static Map initCanonicalLayouts() {
        if (!isSupported()) {
            return null;
        }

        int wchar_size = LibFallback.wcharSize();
        MemoryLayout wchartLayout = switch(wchar_size) {
            case 2 -> JAVA_CHAR; // prefer JAVA_CHAR
            default -> FFIType.layoutFor(wchar_size);
        };

        return Map.ofEntries(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1324996396

From redestad at openjdk.org  Wed Sep 13 19:56:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 13 Sep 2023 19:56:41 GMT
Subject: RFR: 8315789: Minor HexFormat performance improvements [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 8 Sep 2023 10:32:40 GMT, Claes Redestad  wrote:

>> This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat.
>> 
>> This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less:
>> 
>> 
>> Name                               Cnt   Base   Error   Test   Error   Unit   Diff%
>> HexFormatBench.appenderLower        15  1,330 ? 0,021  1,065 ? 0,067  us/op   19,9% (p = 0,000*)
>>   :gc.alloc.rate                    15 11,481 ? 0,185  0,007 ? 0,000 MB/sec  -99,9% (p = 0,000*)
>>   :gc.alloc.rate.norm               15 16,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>>   :gc.count                         15  3,000          0,000         counts
>>   :gc.time                           3  2,000                            ms
>> HexFormatBench.appenderLowerCached  15  1,317 ? 0,013  1,065 ? 0,054  us/op   19,1% (p = 0,000*)
>>   :gc.alloc.rate                    15 11,590 ? 0,111  0,007 ? 0,000 MB/sec  -99,9% (p = 0,000*)
>>   :gc.alloc.rate.norm               15 16,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>>   :gc.count                         15  3,000          0,000         counts
>>   :gc.time                           3  2,000                            ms
>> HexFormatBench.appenderUpper        15  1,330 ? 0,022  1,065 ? 0,036  us/op   19,9% (p = 0,000*)
>>   :gc.alloc.rate                    15 34,416 ? 0,559  0,007 ? 0,000 MB/sec -100,0% (p = 0,000*)
>>   :gc.alloc.rate.norm               15 48,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>>   :gc.count                         15  0,000          0,000         counts
>> HexFormatBench.appenderUpperCached  15  1,353 ? 0,009  1,033 ? 0,014  us/op   23,6% (p = 0,000*)
>>   :gc.alloc.rate                    15 11,284 ? 0,074  0,007 ? 0,000 MB/sec  -99,9% (p = 0,000*)
>>   :gc.alloc.rate.norm               15 16,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>>   :gc.count                         15  3,000          0,000         counts
>>   :gc.time                           3  2,000                            ms
>> HexFormatBench.toHexLower           15  0,198 ? 0,001  0,119 ? 0,008  us/op   40,1% (p = 0,000*)
>>   :gc.alloc.rate                    15  0,007 ? 0,000  0,007 ? 0,000 MB/sec   -0,0% (p = 0,816 )
>>   :gc.alloc.rate.norm               15  0,001 ? 0,000  0,001 ? 0,000   B/op  -40,1% (p = 0,000*)
>>   :gc....
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add toHexDigitsByte|Short|Int|Long microbenchmarks

I ran some experiments with a lookup-table approach (based on `HexDigits` and I can get some of these to be marginally faster when combining a lookup-table approach with the `ByteArray` hack, but there's no win when using one or the other in isolation. So I think much of the win is actually not from using a lookup-table, but from tickling the JIT to inline more and optimize a bit more aggressively. So I think this might be a case of micros telling us sweet little lies, and we should favor the intuition that lookup tables should be avoided unless absolutely necessary.

I prefer the simplicity of this PR as it stands and think we should backtrack on some of the lookup tables we've recently added in `jdk.internal.util.Hex|Decimal|OctalDigits`.

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

PR Comment: https://git.openjdk.org/jdk/pull/15591#issuecomment-1718230389

From aturbanov at openjdk.org  Wed Sep 13 20:00:41 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Sep 2023 20:00:41 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 19:46:08 GMT, Justin Lu  wrote:

>> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
>> 
>> `forceStandardTime` is always false.
>> 
>> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
>> 
>> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove isStandardTime() and inline as false

src/java.base/share/classes/sun/util/calendar/AbstractCalendar.java line 169:

> 167:             }
> 168:             // adjust time zone and daylight saving
> 169:             int[] offsets = new int[2];

Let's move array allocation only to `if (zi instanceof ZoneInfo) {` case

src/java.base/share/classes/sun/util/calendar/AbstractCalendar.java line 177:

> 175:             //    as 1:30am DT/0:30am ST (before transition)
> 176:             if (zi instanceof ZoneInfo) {
> 177:                 zoneOffset = ((ZoneInfo)zi).getOffsetsByWall(ms, offsets);

let's use pattern matching for instanceof

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1325015164
PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1325015642

From jlu at openjdk.org  Wed Sep 13 20:21:20 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 20:21:20 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v3]
In-Reply-To: 
References: 
Message-ID: <08TQdCp46hxMYqcmcx7xXiLwqOcM3KnhBIynidL4Qvo=.605085d1-74f7-423b-98b9-a24fb4b44ceb@github.com>

> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
> 
> `forceStandardTime` is always false.
> 
> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
> 
> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.

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/15726/files
  - new: https://git.openjdk.org/jdk/pull/15726/files/91bd5a3f..5a3375ec

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

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

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

From naoto at openjdk.org  Wed Sep 13 20:22:07 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Sep 2023 20:22:07 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0
Message-ID: 

This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Consonant Break specified in the latest Unicode Annex #29 ("Unicode Text Segmentation") is included. A corresponding CSR has also been drafted.

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

Commit messages:
 - TR29 final version
 - .md file update
 - Final 8/28
 - Draft 8/11
 - GenerateExtraProperties tool
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/15728/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296246
  Stats: 1529 lines in 22 files changed: 1298 ins; 15 del; 216 mod
  Patch: https://git.openjdk.org/jdk/pull/15728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15728/head:pull/15728

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

From aturbanov at openjdk.org  Wed Sep 13 20:35:42 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Sep 2023 20:35:42 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v3]
In-Reply-To: <08TQdCp46hxMYqcmcx7xXiLwqOcM3KnhBIynidL4Qvo=.605085d1-74f7-423b-98b9-a24fb4b44ceb@github.com>
References: 
 <08TQdCp46hxMYqcmcx7xXiLwqOcM3KnhBIynidL4Qvo=.605085d1-74f7-423b-98b9-a24fb4b44ceb@github.com>
Message-ID: 

On Wed, 13 Sep 2023 20:21:20 GMT, Justin Lu  wrote:

>> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
>> 
>> `forceStandardTime` is always false.
>> 
>> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
>> 
>> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comments

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/15726#pullrequestreview-1625404590

From jlu at openjdk.org  Wed Sep 13 20:36:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 20:36:13 GMT
Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for
 j.text.Format classes [v6]
In-Reply-To: 
References: 
Message-ID: 

> 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`).

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

  Replace non-static with instance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15459/files
  - new: https://git.openjdk.org/jdk/pull/15459/files/6fe64f17..b4e7ddd1

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

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

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

From jlu at openjdk.org  Wed Sep 13 20:35:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 20:35:48 GMT
Subject: Integrated: 6228794: java.text.ChoiceFormat pattern behavior is not
 well documented.
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Aug 2023 19:18:35 GMT, Justin Lu  wrote:

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern.
> 
> `j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified.
> 
> The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor.
> 
> The pattern syntax may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html

This pull request has now been integrated.

Changeset: ce93d27f
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/ce93d27fe5725af6424573ceb29cc12f20165f69
Stats:     134 lines in 1 file changed: 87 ins; 18 del; 29 mod

6228794: java.text.ChoiceFormat pattern behavior is not well documented.

Reviewed-by: naoto

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

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

From rriggs at openjdk.org  Wed Sep 13 20:41:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Sep 2023 20:41:39 GMT
Subject: RFR: 8315789: Minor HexFormat performance improvements [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 8 Sep 2023 10:32:40 GMT, Claes Redestad  wrote:

>> This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat.
>> 
>> This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less:
>> 
>> 
>> Name                               Cnt   Base   Error   Test   Error   Unit   Diff%
>> HexFormatBench.appenderLower        15  1,330 ? 0,021  1,065 ? 0,067  us/op   19,9% (p = 0,000*)
>>   :gc.alloc.rate                    15 11,481 ? 0,185  0,007 ? 0,000 MB/sec  -99,9% (p = 0,000*)
>>   :gc.alloc.rate.norm               15 16,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>>   :gc.count                         15  3,000          0,000         counts
>>   :gc.time                           3  2,000                            ms
>> HexFormatBench.appenderLowerCached  15  1,317 ? 0,013  1,065 ? 0,054  us/op   19,1% (p = 0,000*)
>>   :gc.alloc.rate                    15 11,590 ? 0,111  0,007 ? 0,000 MB/sec  -99,9% (p = 0,000*)
>>   :gc.alloc.rate.norm               15 16,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>>   :gc.count                         15  3,000          0,000         counts
>>   :gc.time                           3  2,000                            ms
>> HexFormatBench.appenderUpper        15  1,330 ? 0,022  1,065 ? 0,036  us/op   19,9% (p = 0,000*)
>>   :gc.alloc.rate                    15 34,416 ? 0,559  0,007 ? 0,000 MB/sec -100,0% (p = 0,000*)
>>   :gc.alloc.rate.norm               15 48,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>>   :gc.count                         15  0,000          0,000         counts
>> HexFormatBench.appenderUpperCached  15  1,353 ? 0,009  1,033 ? 0,014  us/op   23,6% (p = 0,000*)
>>   :gc.alloc.rate                    15 11,284 ? 0,074  0,007 ? 0,000 MB/sec  -99,9% (p = 0,000*)
>>   :gc.alloc.rate.norm               15 16,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>>   :gc.count                         15  3,000          0,000         counts
>>   :gc.time                           3  2,000                            ms
>> HexFormatBench.toHexLower           15  0,198 ? 0,001  0,119 ? 0,008  us/op   40,1% (p = 0,000*)
>>   :gc.alloc.rate                    15  0,007 ? 0,000  0,007 ? 0,000 MB/sec   -0,0% (p = 0,816 )
>>   :gc.alloc.rate.norm               15  0,001 ? 0,000  0,001 ? 0,000   B/op  -40,1% (p = 0,000*)
>>   :gc....
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add toHexDigitsByte|Short|Int|Long microbenchmarks

This non-lookup version looks fine; it won't invalidate caches when used and the code is easy to understand.  Thanks for the cleanup and re-checking the performance benefits.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15591#pullrequestreview-1625413399

From redestad at openjdk.org  Wed Sep 13 21:01:57 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 13 Sep 2023 21:01:57 GMT
Subject: Integrated: 8315789: Minor HexFormat performance improvements
In-Reply-To: 
References: 
Message-ID: 

On Wed, 6 Sep 2023 13:36:22 GMT, Claes Redestad  wrote:

> This PR seeks to improve formatting of hex digits using `java.util.HexFormat` somewhat.
> 
> This is achieved getting rid of a couple of lookup tables, caching the result of `HexFormat.of().withUpperCase()`, and removing tiny allocation that happens in the `formatHex(A, byte)` method. Improvements range from 20-40% on throughput, and some operations allocate less:
> 
> 
> Name                               Cnt   Base   Error   Test   Error   Unit   Diff%
> HexFormatBench.appenderLower        15  1,330 ? 0,021  1,065 ? 0,067  us/op   19,9% (p = 0,000*)
>   :gc.alloc.rate                    15 11,481 ? 0,185  0,007 ? 0,000 MB/sec  -99,9% (p = 0,000*)
>   :gc.alloc.rate.norm               15 16,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>   :gc.count                         15  3,000          0,000         counts
>   :gc.time                           3  2,000                            ms
> HexFormatBench.appenderLowerCached  15  1,317 ? 0,013  1,065 ? 0,054  us/op   19,1% (p = 0,000*)
>   :gc.alloc.rate                    15 11,590 ? 0,111  0,007 ? 0,000 MB/sec  -99,9% (p = 0,000*)
>   :gc.alloc.rate.norm               15 16,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>   :gc.count                         15  3,000          0,000         counts
>   :gc.time                           3  2,000                            ms
> HexFormatBench.appenderUpper        15  1,330 ? 0,022  1,065 ? 0,036  us/op   19,9% (p = 0,000*)
>   :gc.alloc.rate                    15 34,416 ? 0,559  0,007 ? 0,000 MB/sec -100,0% (p = 0,000*)
>   :gc.alloc.rate.norm               15 48,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>   :gc.count                         15  0,000          0,000         counts
> HexFormatBench.appenderUpperCached  15  1,353 ? 0,009  1,033 ? 0,014  us/op   23,6% (p = 0,000*)
>   :gc.alloc.rate                    15 11,284 ? 0,074  0,007 ? 0,000 MB/sec  -99,9% (p = 0,000*)
>   :gc.alloc.rate.norm               15 16,009 ? 0,000  0,007 ? 0,000   B/op -100,0% (p = 0,000*)
>   :gc.count                         15  3,000          0,000         counts
>   :gc.time                           3  2,000                            ms
> HexFormatBench.toHexLower           15  0,198 ? 0,001  0,119 ? 0,008  us/op   40,1% (p = 0,000*)
>   :gc.alloc.rate                    15  0,007 ? 0,000  0,007 ? 0,000 MB/sec   -0,0% (p = 0,816 )
>   :gc.alloc.rate.norm               15  0,001 ? 0,000  0,001 ? 0,000   B/op  -40,1% (p = 0,000*)
>   :gc.count                         15  0,000          0,000    ...

This pull request has now been integrated.

Changeset: 92ad4a23
Author:    Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/92ad4a2399bb06b36b167a60c00d2299917fca9f
Stats:     210 lines in 2 files changed: 182 ins; 9 del; 19 mod

8315789: Minor HexFormat performance improvements

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Wed Sep 13 21:25:48 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 21:25:48 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 
Message-ID: 

On Wed, 13 Sep 2023 19:21:34 GMT, Roger Riggs  wrote:

> Based on the use cases cited, if your library needs specific performance improvements for specific formats, they should be done in that library.

I already do this in [fastjson2](https://github.com/alibaba/fastjson2) for now, but more libraries would benefit if improved in jdk.

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718334638

From duke at openjdk.org  Wed Sep 13 22:03:45 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 22:03:45 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: 

On Wed, 13 Sep 2023 14:22:35 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify LocalDate::getChars

> As a consideration to core-libs-dev readers, push commits when you are convinced are ready for review and you don't intend to make more changes. It will improve the signal to noise ratio. Thanks



> As a consideration to core-libs-dev readers, push commits when you are convinced are ready for review and you don't intend to make more changes. It will improve the signal to noise ratio. Thanks

Sorry, I will make sure to do more preparation before submitting any PRs in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718372907

From duke at openjdk.org  Wed Sep 13 22:37:46 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 13 Sep 2023 22:37:46 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 
 
Message-ID: 

On Wed, 13 Sep 2023 21:22:43 GMT, ???  wrote:

> Based on the use cases cited, if your library needs specific performance improvements for specific formats, they should be done in that library.

Not only JSON libraries, toString optimization of Date/Instant/LocalDateTime and other classes will benefit in many places, such as logging in business systems, etc.


Instant bizTime = ...;
LOG.log(Level.INFO, "bizDate {0}", bizTime);

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

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1718401009

From naoto at openjdk.org  Wed Sep 13 22:57:38 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Sep 2023 22:57:38 GMT
Subject: RFR: 8316187: Modernize an example in StringTokenizer
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 12:39:00 GMT, Pavel Rappo  wrote:

> This modernizes an example to use the extended for-statement introduced in JDK 1.5.
> 
> I understand that StringTokenizer is a legacy class. But legacy or not, a class shouldn't promote older constructs when newer fit better. Especially when advising on preferred alternatives to itself.
> 
> That said, I wouldn't go as far as to use `var` anywhere in that example: JDK 10, which introduced `var`, might still be relatively new to some. Nor would I inline the call to `String.split` in the for-statement to dispense with the `String[] result` variable: I reckon it's good for a reader unfamiliar with `String.split` to see the type it returns.
> 
> Perhaps one additional thing to ponder is this: we could either add `@see` to point to `String.split` or make the whole example a `@snippet`, which `@link`s code to the definition of `String.split`.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15716#pullrequestreview-1625561688

From naoto at openjdk.org  Wed Sep 13 22:59:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Sep 2023 22:59:42 GMT
Subject: RFR: 8316207: Fix typos in java.io.StreamTokenizer
In-Reply-To: <6x1Hpv-9vQ5hyP6KSDcFEshLeWKpT0BaVyw_HnlusYk=.28bb20b8-2c84-4218-b2f3-2a31196a31cb@github.com>
References: <6x1Hpv-9vQ5hyP6KSDcFEshLeWKpT0BaVyw_HnlusYk=.28bb20b8-2c84-4218-b2f3-2a31196a31cb@github.com>
Message-ID: 

On Wed, 13 Sep 2023 15:43:45 GMT, Pavel Rappo  wrote:

> This is a simple PR to fix a few typos in the doc comments of java.io.StreamTokenizer. When reviewing it, please double-check my proposal for L481. For this, you should ideally read the complete comment to the `lowerCaseMode` method. Thanks!

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15723#pullrequestreview-1625562814

From duke at openjdk.org  Wed Sep 13 23:00:23 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 13 Sep 2023 23:00:23 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v36]
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 incrementally with one additional commit since the last revision:

  Refactor the sort and partition intrinsics to accept method references for fallback functions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/ed8b95c9..172b2d3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=34-35

  Stats: 251 lines in 14 files changed: 63 ins; 106 del; 82 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  Wed Sep 13 23:04:52 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 13 Sep 2023 23:04:52 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v36]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 23:00:23 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:
> 
>   Refactor the sort and partition intrinsics to accept method references for fallback functions

Hello Paul,

As per your suggestion, I've made the changes to pass a method reference to the sort and partition intrinsics (to be used as the fallback method) using the code snippet inspired by Vector API you showed below. It looks much cleaner now.

Could you please have a look at the changes in `DualPivotQuicksort.java` and provide your feedback?
>
> ```java
> @FunctionalInterface
> interface SortOperation {
>   void sort(A a, int low, int end int high);
> }
> 
> // A erases to Object in bytecode so i think it should work
> @IntrinsicCandidate
> @ForceInline
> private static  void arraySort(Class eClass, A a, long offset, int low, int end, int high, SortOperation so) {
>    so.sort(a, low, end, high);
> }
> ```
>

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1718420889

From duke at openjdk.org  Thu Sep 14 02:21:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 14 Sep 2023 02:21:13 GMT
Subject: RFR: 8316235: Optimization for DateTimeFormatter::format
Message-ID: 

In many scenarios, DateTimeFormatter::format is a slower operation.  

For example, the following business scenarios
1. The json library gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings.
2. In data integration scenarios, for projects like  [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), if the input type is Date/Instant and the output type is String, formatting is required.

This PR provides format performance optimization for commonly used date patterns.

ISO_INSTANT
ISO_LOCAL_TIME
ISO_LOCAL_DATE
ISO_LOCAL_DATETIME
HH:mm:ss
HH:mm:ss.SSS
yyyy-MM-dd
yyyy-MM-dd HH:mm:ss
yyyy-MM-dd'T'HH:mm:ss
yyyy-MM-dd HH:mm:ss.SSS
yyyy-MM-dd'T'HH:mm:ss.SSS

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

Commit messages:
 - fix format LocalTime/LocalDateTime use utc
 - fix format ZonedDateTime & OffsetDateTime & OffsetTime use utc
 - sealed class CompositePrinterParser
 - use Pattern Matching switch
 - remove LocalTimePrinterParser::format support Instant
 - optimization support pattern 'yyyy-MM-dd HH:mm:ss.SSS'
 - remove digit_k
 - optimize DateTimeFormatter::format
 - fix InstantPrinterParser miss nanos
 - remove TimeCompositePrinterParser, fix build error
 - ... and 1 more: https://git.openjdk.org/jdk/compare/e0845163...564ae18b

Changes: https://git.openjdk.org/jdk/pull/15722/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15722&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316235
  Stats: 418 lines in 6 files changed: 341 ins; 51 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/15722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15722/head:pull/15722

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

From duke at openjdk.org  Thu Sep 14 02:21:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 14 Sep 2023 02:21:13 GMT
Subject: RFR: 8316235: Optimization for DateTimeFormatter::format
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 14:56:15 GMT, ???  wrote:

> In many scenarios, DateTimeFormatter::format is a slower operation.  
> 
> For example, the following business scenarios
> 1. The json library gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings.
> 2. In data integration scenarios, for projects like  [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), if the input type is Date/Instant and the output type is String, formatting is required.
> 
> This PR provides format performance optimization for commonly used date patterns.
> 
> ISO_INSTANT
> ISO_LOCAL_TIME
> ISO_LOCAL_DATE
> ISO_LOCAL_DATETIME
> HH:mm:ss
> HH:mm:ss.SSS
> yyyy-MM-dd
> yyyy-MM-dd HH:mm:ss
> yyyy-MM-dd'T'HH:mm:ss
> yyyy-MM-dd HH:mm:ss.SSS
> yyyy-MM-dd'T'HH:mm:ss.SSS

Performance comparison data is as follows:

## 1. Script

bash configure
make images
sh make/devkit/createJMHBundle.sh
bash configure --with-jmh=build/jmh/jars
make test TEST="micro:java.time.format.DateTimeFormatterBench.*"


## 2. MacBookPro benchmark 

-Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units (baseline)
-DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  14.888 ? 0.109  ops/ms
-DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  10.132 ? 0.046  ops/ms
-DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15   8.993 ? 0.039  ops/ms
-DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   7.400 ? 0.035  ops/ms
-DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  21.460 ? 0.056  ops/ms
-DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  14.439 ? 0.264  ops/ms
-DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  12.742 ? 0.055  ops/ms
-DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15   9.059 ? 0.124  ops/ms

+Benchmark                                                   (pattern)   Mode  Cnt   Score   Error   Units (optimized)
+DateTimeFormatterBench.formatInstants                        HH:mm:ss  thrpt   15  28.082 ? 0.284  ops/ms (+88.62%)
+DateTimeFormatterBench.formatInstants                    HH:mm:ss.SSS  thrpt   15  25.483 ? 0.109  ops/ms (+151.51%)
+DateTimeFormatterBench.formatInstants           yyyy-MM-dd'T'HH:mm:ss  thrpt   15  19.950 ? 0.444  ops/ms (+121.83%)
+DateTimeFormatterBench.formatInstants       yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  18.391 ? 0.327  ops/ms (+148.52%)
+DateTimeFormatterBench.formatZonedDateTime                   HH:mm:ss  thrpt   15  57.870 ? 0.641  ops/ms (+169.66%)
+DateTimeFormatterBench.formatZonedDateTime               HH:mm:ss.SSS  thrpt   15  43.783 ? 0.300  ops/ms (+203.22%)
+DateTimeFormatterBench.formatZonedDateTime      yyyy-MM-dd'T'HH:mm:ss  thrpt   15  36.220 ? 0.194  ops/ms (+184.25%)
+DateTimeFormatterBench.formatZonedDateTime  yyyy-MM-dd'T'HH:mm:ss.SSS  thrpt   15  32.512 ? 0.583  ops/ms (+258.89%)

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

PR Comment: https://git.openjdk.org/jdk/pull/15722#issuecomment-1717870613

From duke at openjdk.org  Thu Sep 14 02:21:14 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 14 Sep 2023 02:21:14 GMT
Subject: RFR: 8316235: Optimization for DateTimeFormatter::format
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 14:56:15 GMT, ???  wrote:

> In many scenarios, DateTimeFormatter::format is a slower operation.  
> 
> For example, the following business scenarios
> 1. The json library gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings.
> 2. In data integration scenarios, for projects like  [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), if the input type is Date/Instant and the output type is String, formatting is required.
> 
> This PR provides format performance optimization for commonly used date patterns.
> 
> ISO_INSTANT
> ISO_LOCAL_TIME
> ISO_LOCAL_DATE
> ISO_LOCAL_DATETIME
> HH:mm:ss
> HH:mm:ss.SSS
> yyyy-MM-dd
> yyyy-MM-dd HH:mm:ss
> yyyy-MM-dd'T'HH:mm:ss
> yyyy-MM-dd HH:mm:ss.SSS
> yyyy-MM-dd'T'HH:mm:ss.SSS

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2594:

> 2592:             } else {
> 2593:                 return super.format(context, buf);
> 2594:             }

This?can?use `instanceof?`:
Suggestion:

            if (temporal instanceof LocalDateTime ldt) {
                date = ldt.toLocalDate();
            } else if (temporal instanceof LocalDate ld) {
                date = ld;
            } else if (temporal instanceof ZonedDateTime zdt) {
                date = zdt.toLocalDate();
            } else if (temporal instanceof OffsetDateTime odt) {
                date = odt.toLocalDate();
            } else {
                return super.format(context, buf);
            }


Or?even a?pattern?switch:
Suggestion:

            switch (temporal) {
                case LocalDateTime ldt -> date = ldt.toLocalDate();
                case LocalDate ld -> date = ld;
                case ZonedDateTime zdt -> date = zdt.toLocalDate();
                case OffsetDateTime odt -> date = odt.toLocalDate();
                default -> {
                    return super.format(context, buf);
                }
            }

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2661:

> 2659:             } else {
> 2660:                 return super.format(context, buf);
> 2661:             }

This?can?use `instanceof?`:
Suggestion:

            if (temporal instanceof LocalTime lt) {
                time = lt;
            } else if (temporal instanceof LocalDateTime ldt) {
                time = ldt.toLocalTime();
            } else if (temporal instanceof ZonedDateTime zdt) {
                time = zdt.toLocalTime();
            } else if (temporal instanceof OffsetDateTime odt) {
                time = odt.toLocalTime();
            } else if (temporal instanceof OffsetTime ot) {
                time = ot.toLocalTime();
            } else {
                return super.format(context, buf);
            }


Or?even a?pattern?switch:
Suggestion:

            switch (temporal) {
                case LocalTime lt -> time = lt;
                case LocalDateTime ldt -> time = ldt.toLocalTime();
                case ZonedDateTime zdt -> time = zdt.toLocalTime();
                case OffsetDateTime odt -> time = odt.toLocalTime();
                case OffsetTime ot -> time = ot.toLocalTime();
                default -> {
                    return super.format(context, buf);
                }
            }

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2683:

> 2681:      * Composite printer and parser.
> 2682:      */
> 2683:     static class CompositePrinterParser implements DateTimePrinterParser {

This?class can?be?`sealed`:
Suggestion:

    static sealed class CompositePrinterParser implements DateTimePrinterParser {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1324933754
PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1324937172
PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1324941838

From duke at openjdk.org  Thu Sep 14 02:21:14 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 14 Sep 2023 02:21:14 GMT
Subject: RFR: 8316235: Optimization for DateTimeFormatter::format
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 18:52:21 GMT, ExE Boss  wrote:

>> In many scenarios, DateTimeFormatter::format is a slower operation.  
>> 
>> For example, the following business scenarios
>> 1. The json library gson/jackson/[fastjson2](https://github.com/alibaba/fastjson2) formats Instant/LocalDate/LocalTime/LocalDateTime/ZonedDateTim into strings.
>> 2. In data integration scenarios, for projects like  [datax](https://github.com/alibaba/datax)/[canal](https://github.com/alibaba/canal), if the input type is Date/Instant and the output type is String, formatting is required.
>> 
>> This PR provides format performance optimization for commonly used date patterns.
>> 
>> ISO_INSTANT
>> ISO_LOCAL_TIME
>> ISO_LOCAL_DATE
>> ISO_LOCAL_DATETIME
>> HH:mm:ss
>> HH:mm:ss.SSS
>> yyyy-MM-dd
>> yyyy-MM-dd HH:mm:ss
>> yyyy-MM-dd'T'HH:mm:ss
>> yyyy-MM-dd HH:mm:ss.SSS
>> yyyy-MM-dd'T'HH:mm:ss.SSS
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2661:
> 
>> 2659:             } else {
>> 2660:                 return super.format(context, buf);
>> 2661:             }
> 
> This?can?use `instanceof?`:
> Suggestion:
> 
>             if (temporal instanceof LocalTime lt) {
>                 time = lt;
>             } else if (temporal instanceof LocalDateTime ldt) {
>                 time = ldt.toLocalTime();
>             } else if (temporal instanceof ZonedDateTime zdt) {
>                 time = zdt.toLocalTime();
>             } else if (temporal instanceof OffsetDateTime odt) {
>                 time = odt.toLocalTime();
>             } else if (temporal instanceof OffsetTime ot) {
>                 time = ot.toLocalTime();
>             } else {
>                 return super.format(context, buf);
>             }
> 
> 
> Or?even a?pattern?switch:
> Suggestion:
> 
>             switch (temporal) {
>                 case LocalTime lt -> time = lt;
>                 case LocalDateTime ldt -> time = ldt.toLocalTime();
>                 case ZonedDateTime zdt -> time = zdt.toLocalTime();
>                 case OffsetDateTime odt -> time = odt.toLocalTime();
>                 case OffsetTime ot -> time = ot.toLocalTime();
>                 default -> {
>                     return super.format(context, buf);
>                 }
>             }

It's a good idea to use the new switch syntax

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2683:
> 
>> 2681:      * Composite printer and parser.
>> 2682:      */
>> 2683:     static class CompositePrinterParser implements DateTimePrinterParser {
> 
> This?class can?be?`sealed`:
> Suggestion:
> 
>     static sealed class CompositePrinterParser implements DateTimePrinterParser {

Changes have been made based on your suggestions

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1325113374
PR Review Comment: https://git.openjdk.org/jdk/pull/15722#discussion_r1325112780

From david.holmes at oracle.com  Thu Sep 14 02:33:02 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 Sep 2023 12:33:02 +1000
Subject: Java 21 clinit deadlock
In-Reply-To: 
References: 
 <77f901c7-5bb8-4703-8c64-b331913516b6@oracle.com>
 
 
 
 
Message-ID: <9eb34d59-f00d-4a73-9eaf-5353b4ba5838@oracle.com>

Hi Simone,

On 13/09/2023 4:16 pm, Simone Bordet wrote:
> Hi,
> 
> On Tue, Sep 12, 2023 at 11:44?PM David Holmes  wrote:
>>
>> Hi Simone,
>>
>> Thanks for the logs. Unfortunately they shed no light on what is
>> happening. There is no sign of the MutableHttpFields class starting
>> actual initialization, though we can see that it was linked (verified).
>> And there are no exceptions indicated relevant to the class loading and
>> initialization process that I can discern.
>>
>> The class initialization logging is unfortunately rather sparse and I
>> think we would need to add some additional logging to shed further light
>> on this. Are you in a position to patch the sources, create a custom
>> build and test again with that build?
> 
> Yes we can do this.

I've created a draft PR here:

https://github.com/openjdk/jdk/pull/15732

can you apply that patch, build and re-test? Hopefully that will show 
which thread is doing the missing initialization.

Thanks,
David


From martin at openjdk.org  Thu Sep 14 04:31:41 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 14 Sep 2023 04:31:41 GMT
Subject: RFR: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 12:27:39 GMT, Soumadipta Roy  wrote:

>> This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations:
>> 
>> * before                           : **200.64s user 20.94s system 204% cpu 1:48.47 total**
>> * fully parallel                  : **308.84s user 23.75s system 479% cpu 1:09.42 total**
>> * default-details-tck       : **244.69s user 22.03s system 314% cpu 1:24.94 total**
>> * default-fjp_details-others : **260.12s user 24.47s system 404% cpu 1:10.31 total**
>> 
>> Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination.
>
> Soumadipta Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding summary for each parallelized section.

Marked as reviewed by martin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15619#pullrequestreview-1625807482

From martin at openjdk.org  Thu Sep 14 04:31:42 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 14 Sep 2023 04:31:42 GMT
Subject: RFR: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 7 Sep 2023 16:22:18 GMT, Soumadipta Roy  wrote:

>> test/jdk/java/util/concurrent/tck/JSR166TestCase.java line 45:
>> 
>>> 43:  * @modules java.management
>>> 44:  * @run junit/othervm/timeout=1000 JSR166TestCase
>>> 45:  * @run junit/othervm/timeout=1000 -Djava.security.manager=allow JSR166TestCase
>> 
>> security manager testing is relatively less important.   I would move this to a lower tier, while moving a test with -Djsr166.testImplementationDetails=true into tier1
>
> Hi Martin,
> 
> I will raise another commit trying to add summary for the segregations

I still think the test with -Djava.security.manager=allow is relatively low value, so would also move it into its own @test id=security-manager

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15619#discussion_r1325339151

From duke at openjdk.org  Thu Sep 14 08:08:18 2023
From: duke at openjdk.org (Soumadipta Roy)
Date: Thu, 14 Sep 2023 08:08:18 GMT
Subject: RFR: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java [v4]
In-Reply-To: 
References: 
Message-ID: 

> This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations:
> 
> * before                           : **200.64s user 20.94s system 204% cpu 1:48.47 total**
> * fully parallel                  : **308.84s user 23.75s system 479% cpu 1:09.42 total**
> * default-details-tck       : **244.69s user 22.03s system 314% cpu 1:24.94 total**
> * default-fjp_details-others : **260.12s user 24.47s system 404% cpu 1:10.31 total**
> 
> Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination.

Soumadipta Roy has updated the pull request incrementally with two additional commits since the last revision:

 - Changing test id name from security-manager-allow to security-manager
 - Creating a separate parallelized test for java.security.manager=allow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15619/files
  - new: https://git.openjdk.org/jdk/pull/15619/files/12e1a02a..74b97be9

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

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

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

From duke at openjdk.org  Thu Sep 14 08:08:18 2023
From: duke at openjdk.org (Soumadipta Roy)
Date: Thu, 14 Sep 2023 08:08:18 GMT
Subject: RFR: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 14 Sep 2023 04:29:17 GMT, Martin Buchholz  wrote:

>> Soumadipta Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding summary for each parallelized section.
>
> Marked as reviewed by martin (Reviewer).

Hi @Martin-Buchholz I have created a separate test case for security manager as you requested. The deviations of user and system times are very less from the initial comment and with total running time improvement: **285.76s user 23.37s system 492% cpu 1:02.76 total**.
Request your re-approval on the latest changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/15619#issuecomment-1718958325

From aturbanov at openjdk.org  Thu Sep 14 09:03:47 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 14 Sep 2023 09:03:47 GMT
Subject: Integrated: 8315973: Remove unused fields from ThreadLocalRandom
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Aug 2023 15:07:45 GMT, Andrey Turbanov  wrote:

> These messages were used before [JDK-8248862](https://bugs.openjdk.org/browse/JDK-8248862)

This pull request has now been integrated.

Changeset: 14408bc8
Author:    Andrey Turbanov 
URL:       https://git.openjdk.org/jdk/commit/14408bc8f846447312fd18dde1f8c615ddad61c0
Stats:     9 lines in 1 file changed: 0 ins; 9 del; 0 mod

8315973: Remove unused fields from ThreadLocalRandom

Reviewed-by: jpai

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

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

From alanb at openjdk.org  Thu Sep 14 10:24:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Sep 2023 10:24:05 GMT
Subject: RFR: 8316160: Remove
 sun.misc.Unsafe.{shouldBeInitialized,ensureClassInitialized}
Message-ID: 

Unsafe.{shouldBeInitialized,ensureClassInitialized} are deprecated for removal since JDK 15. It's time to remove them. Lookup.ensureInitialized(Class) was added in Java 15 as a standard API to ensure that an accessible class is initialized. 

A search of 175973022 classes in 484751 artifacts found:
- 23 usages of Unsafe.shouldBeInitialized, of which 8 are unique
- 121 usages of Unsafe.ensureClassInitialized, of which 31 are unique

Not a lot of usage, many of the usages seem to be code compiled to older releases.

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

Commit messages:
 - Initial commit

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

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

From duke at openjdk.org  Thu Sep 14 11:19:08 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 14 Sep 2023 11:19:08 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v15]
In-Reply-To: 
References: 
Message-ID: 

> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal.
> 
> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance.
> 
> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering.
> 
> The performance data is as follows: 
> 
> ## 1. benchmark script
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.math.BigDecimals.*ToPlainString"
> make test TEST="micro:java.math.BigDecimals.*ToEngineering"
> 
> 
> ## 2. benchmark environment
> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i)
> * cpu intel xeon sapphire rapids (x64)
> 
> ## 3. benchmark result
> 
> -BigDecimals.testHugeToPlainString         avgt   15   188.691 ?  0.822  ns/op  (baseline)
> -BigDecimals.testLargeToPlainString        avgt   15    36.656 ?  0.065  ns/op
> -BigDecimals.testSmallToPlainString        avgt   15    34.342 ?  0.068  ns/op
> -BigDecimals.testToPlainString             avgt   15  1719.494 ? 24.886  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
> +BigDecimals.testHugeToPlainString         avgt   15   133.972 ?  0.328  ns/op (+40.84%)
> +BigDecimals.testLargeToPlainString        avgt   15    14.957 ?  0.047  ns/op (145.07%)
> +BigDecimals.testSmallToPlainString        avgt   15    12.045 ?  0.036  ns/op (+185.11)
> +BigDecimals.testToPlainString             avgt   15  1643.500 ?  3.217  ns/op (+4.62%)
> 
> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
> -BigDecimals.testHugeToEngineeringString   avgt   15   207.621 ?  5.018  ns/op
> -BigDecimals.testLargeToEngineeringString  avgt   15    35.658 ?  3.144  ns/op
> -BigDecimals.testSmallToEngineeringString  avgt   15    15.142 ?  0.053  ns/op
> -BigDecimals.testToEngineeringString       avgt   15  1813.959 ? 12.842  ns/op
> 
> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
> +BigDecimals.testHugeToEngineeringString   avgt   15   142.110 ?  0.987  ns/op (+45.09%)
> +BigDecimals.testLargeToEngineeringString  avgt   15    12.509 ?  0.056  ns/op (+185.05%)
> +BigDecimals.testSmallToEngineer...

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

  revert JavaLangAccess and use DecimalDigits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15555/files
  - new: https://git.openjdk.org/jdk/pull/15555/files/4ffbb235..db1c3167

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

  Stats: 170 lines in 5 files changed: 87 ins; 45 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/15555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15555/head:pull/15555

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

From pminborg at openjdk.org  Thu Sep 14 12:09:23 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 14 Sep 2023 12:09:23 GMT
Subject: RFR: 8316190: Improve MemorySegment::toString
Message-ID: 

This PR proposes to improve the MemorySegment::toString to reduce cluttering and add missing comas.

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

Commit messages:
 - Improve MemorySegment::toString

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

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

From pminborg at openjdk.org  Thu Sep 14 12:09:26 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 14 Sep 2023 12:09:26 GMT
Subject: RFR: 8316190: Improve MemorySegment::toString
In-Reply-To: 
References: 
Message-ID: 

On Thu, 14 Sep 2023 12:01:29 GMT, Per Minborg  wrote:

> This PR proposes to improve the MemorySegment::toString to reduce cluttering and add missing comas.

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 277:

> 275:     }
> 276: 
> 277:     public static String toHexString(long value) {

We intend to use this utility method in coming PRs.

test/jdk/java/foreign/TestSegments.java line 251:

> 249:                 () -> MemorySegment.ofArray(new float[] { 1.0f, 2.0f, 3.0f, 4.0f }),
> 250:                 () -> MemorySegment.ofArray(new int[] { 1, 2, 3, 4 }),
> 251:                 () -> MemorySegment.ofArray(new long[] { 1L, 2L, 3L, 4L } ),

Drive-by fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15740#discussion_r1325845210
PR Review Comment: https://git.openjdk.org/jdk/pull/15740#discussion_r1325844029

From alanb at openjdk.org  Thu Sep 14 13:30:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Sep 2023 13:30:28 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v3]
In-Reply-To: 
References: 
Message-ID: 

> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue with debuggers because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
> 
> The change is straight-forward with additional state for timed-parking/parked/pinned. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.

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

 - Merge
 - Revert back to explicit TIMED_xxx states
 - Merge
 - Merge
 - Merge
 - Remove unecessary RF from test
 - Merge
 - Merge
 - Remove tab
 - Cleanup comments
 - ... and 4 more: https://git.openjdk.org/jdk/compare/d592852e...70b7766d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14978/files
  - new: https://git.openjdk.org/jdk/pull/14978/files/7b9e0d5a..70b7766d

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

  Stats: 6773 lines in 809 files changed: 3800 ins; 1939 del; 1034 mod
  Patch: https://git.openjdk.org/jdk/pull/14978.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14978/head:pull/14978

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

From alanb at openjdk.org  Thu Sep 14 13:30:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Sep 2023 13:30:30 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 27 Jul 2023 01:54:58 GMT, Serguei Spitsyn  wrote:

> Looks good.
> Thanks,
> Serguei

Thanks Serguei. I had to pause this to work on other things. When I sync'ed up the branch I found I had to update recently introduced test jvmti/vthread/VThreadEventTest/VThreadEventTest.java as it was checking for WAITING.

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

PR Comment: https://git.openjdk.org/jdk/pull/14978#issuecomment-1719447522

From alanb at openjdk.org  Thu Sep 14 13:32:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Sep 2023 13:32:42 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v3]
In-Reply-To: 
References: 
 <2rTLX86raFjJBNOlUysJoxGB8UaGLH7szSa_EOmXEDE=.e545fc08-9354-4173-b88f-b8173c3878b7@github.com>
 
 
Message-ID: 

On Wed, 26 Jul 2023 12:18:02 GMT, David Holmes  wrote:

> Yes but TIMED and SUSPENDED are not alike. I assume SUSPENDED is a stand-alone bit because you can be in various states and suspended at the same time. But TIMED isn't like that.

The SUSPENDED bit can only be set when the virtual thread is unmounted, so limited to the RUNNABLE and PARKED states at this time.

The intention with TIMED was that it could be OR'ed with PARKING, PARKED or PINNED to quality that they are timed rather than untimed. It wouldn't make sense in other states.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1325955801

From rriggs at openjdk.org  Thu Sep 14 13:47:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Sep 2023 13:47:41 GMT
Subject: RFR: 8316190: Improve MemorySegment::toString
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 14 Sep 2023 12:02:53 GMT, Per Minborg  wrote:

>> This PR proposes to improve the MemorySegment::toString to reduce cluttering and add missing comas.
>
> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 277:
> 
>> 275:     }
>> 276: 
>> 277:     public static String toHexString(long value) {
> 
> We intend to use this utility method in coming PRs.

The String concat code is really good at optimizing, but this will require a new string be created.
$0.02,Roger

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15740#discussion_r1325977796

From pminborg at openjdk.org  Thu Sep 14 13:53:51 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 14 Sep 2023 13:53:51 GMT
Subject: RFR: 8316196: VarHandleSegmentViewBase::newIllegalArg... to use
 hexadecimal form
Message-ID: 

This PR proposes to use hexadecimal formatting for raw addresses in `VarHandleSegmentViewBase`.

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

Commit messages:
 - VarHandleSegmentViewBase::newIllegalArg... to use hexadecimal form

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

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

From pminborg at openjdk.org  Thu Sep 14 13:53:53 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 14 Sep 2023 13:53:53 GMT
Subject: RFR: 8316196: VarHandleSegmentViewBase::newIllegalArg... to use
 hexadecimal form
In-Reply-To: 
References: 
Message-ID: 

On Thu, 14 Sep 2023 13:45:30 GMT, Per Minborg  wrote:

> This PR proposes to use hexadecimal formatting for raw addresses in `VarHandleSegmentViewBase`.

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 277:

> 275:     }
> 276: 
> 277:     public static String toHexString(long value) {

This method also exist in another PR which is not merged into the mainline yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15742#discussion_r1325979294

From martin at openjdk.org  Thu Sep 14 14:08:42 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 14 Sep 2023 14:08:42 GMT
Subject: RFR: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 14 Sep 2023 08:08:18 GMT, Soumadipta Roy  wrote:

>> This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations:
>> 
>> * before                           : **200.64s user 20.94s system 204% cpu 1:48.47 total**
>> * fully parallel                  : **308.84s user 23.75s system 479% cpu 1:09.42 total**
>> * default-details-tck       : **244.69s user 22.03s system 314% cpu 1:24.94 total**
>> * default-fjp_details-others : **260.12s user 24.47s system 404% cpu 1:10.31 total**
>> 
>> Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination.
>
> Soumadipta Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changing test id name from security-manager-allow to security-manager
>  - Creating a separate parallelized test for java.security.manager=allow

Thanks!

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

Marked as reviewed by martin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15619#pullrequestreview-1626980624

From shade at openjdk.org  Thu Sep 14 14:15:40 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Sep 2023 14:15:40 GMT
Subject: RFR: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 14 Sep 2023 08:08:18 GMT, Soumadipta Roy  wrote:

>> This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations:
>> 
>> * before                           : **200.64s user 20.94s system 204% cpu 1:48.47 total**
>> * fully parallel                  : **308.84s user 23.75s system 479% cpu 1:09.42 total**
>> * default-details-tck       : **244.69s user 22.03s system 314% cpu 1:24.94 total**
>> * default-fjp_details-others : **260.12s user 24.47s system 404% cpu 1:10.31 total**
>> 
>> Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination.
>
> Soumadipta Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changing test id name from security-manager-allow to security-manager
>  - Creating a separate parallelized test for java.security.manager=allow

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15619#pullrequestreview-1626998045

From rriggs at openjdk.org  Thu Sep 14 14:16:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Sep 2023 14:16:39 GMT
Subject: RFR: 8316190: Improve MemorySegment::toString
In-Reply-To: 
References: 
Message-ID: <6xaQWY_Yb4iJjaEklwUPW8mmrw5aztj74xyGiNSKrFM=.1c776bfe-2d0a-4faa-b5c9-8b0698fb1542@github.com>

On Thu, 14 Sep 2023 12:01:29 GMT, Per Minborg  wrote:

> This PR proposes to improve the MemorySegment::toString to reduce cluttering and add missing comas.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15740#pullrequestreview-1626999067

From redestad at openjdk.org  Thu Sep 14 14:26:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 14 Sep 2023 14:26:41 GMT
Subject: RFR: 8316190: Improve MemorySegment::toString
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 14 Sep 2023 13:44:59 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 277:
>> 
>>> 275:     }
>>> 276: 
>>> 277:     public static String toHexString(long value) {
>> 
>> We intend to use this utility method in coming PRs.
>
> The String concat code is really good at optimizing, but this will require a new string be created.
> $0.02,Roger

Why not `HexFormat.of().withPrefix("0x").formatHexString(long)` I thought, then realized there's no such method, only `toHexDigits` which ignores the `HexFormat.prefix`. Having a format method that adds the prefix (and any suffix + delimiters) means creating this string could be done in a single step without concatenation, and we'd consolidate all manners of usage to a single place. Seems there might be room for improvement here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15740#discussion_r1326032912

From mullan at openjdk.org  Thu Sep 14 15:05:52 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Sep 2023 15:05:52 GMT
Subject: RFR: 8312126: NullPointerException in CertStore.getCRLs after 8297955
Message-ID: <_VhiuO9MT7lq87Dq_4-h54mi9D1X2bqalr0Wm2squc8=.56efd2cc-f9ef-4438-a7eb-c3227a2dd8a6@github.com>

Please review this fix for a regression in the LDAP CertStore implementation where a null CRL issuerName in an X509CRLSelector should be treated as a CertStoreException instead of a NullPointerException.

A new test has been added but requires internal infrastructure so will only be in the closed.

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

Commit messages:
 - Initial fix.

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

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

From duke at openjdk.org  Thu Sep 14 15:24:45 2023
From: duke at openjdk.org (Soumadipta Roy)
Date: Thu, 14 Sep 2023 15:24:45 GMT
Subject: RFR: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 14 Sep 2023 14:05:36 GMT, Martin Buchholz  wrote:

>> Soumadipta Roy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Changing test id name from security-manager-allow to security-manager
>>  - Creating a separate parallelized test for java.security.manager=allow
>
> Thanks!

Hi @Martin-Buchholz can you please sponsor the PR

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

PR Comment: https://git.openjdk.org/jdk/pull/15619#issuecomment-1719665847

From lancea at openjdk.org  Thu Sep 14 15:57:43 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 15:57:43 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v2]
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 incrementally with one additional commit since the last revision:

  Added additional tests, along with additional cleanup and refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/bb962fcf..40504b2c

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

  Stats: 737 lines in 3 files changed: 578 ins; 99 del; 60 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 lancea at openjdk.org  Thu Sep 14 15:57:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 15:57:45 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 11 Sep 2023 23:42:37 GMT, Sergey Bylokhov  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added additional tests, along with additional cleanup and refactoring
>
> test/jdk/java/util/zip/ZipFile/MissingZIP64EntriesTest.java line 52:
> 
>> 50:  * starting number is set to 0xFFFF or when we have a valid Zip64 Extra header
>> 51:  * size but missing the corresponding field.
>> 52:  * @run junit MissingZIP64EntriesTest
> 
> Is this comment accurate? I think we should check 3 cases when the header extra len == 0, len == 8 and len ==16, but still do not contain all required information.

Clarified the comment to make it a bit clearer and also added additional tests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15650#discussion_r1326168515

From lancea at openjdk.org  Thu Sep 14 15:57:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 15:57:48 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 12 Sep 2023 08:47:03 GMT, Andrey Turbanov  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added additional tests, along with additional cleanup and refactoring
>
> test/jdk/java/util/zip/ZipFile/MissingZIP64EntriesTest.java line 198:
> 
>> 196:      * actual value is stored in the Zip64 Extra Header
>> 197:      */
>> 198:     private static final int  ZIP64_MAGICCOUNT = 0xFFFF;
> 
> Suggestion:
> 
>     private static final int ZIP64_MAGICCOUNT = 0xFFFF;

Removed the extra space.  thank you for pointing it out

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15650#discussion_r1326169219

From shade at openjdk.org  Thu Sep 14 16:08:42 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Sep 2023 16:08:42 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Aug 2023 20:00:49 GMT, Nikita Sakharin  wrote:

>> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
>> 
>> final int size = (1 << 30) + 1;
>> final List list = new ArrayList<>(size);
>> for (int i = 0; i < size; ++i)
>>     list.add((byte) 0);
>> Collections.rotate(list, size - 1);
>> 
>> Output:
>> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
>> 
>> In that case private method `Collections.rotate1` will be called. And the line:
>> `i += distance;`
>> will cause overflow. I fixed this method and wrote a test for it.
>> 
>> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
>> 
>> Kindly ask you to raise a bug.
>
> Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314236: add comment for test

OK, looks reasonable.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15270#pullrequestreview-1627275045

From lancea at openjdk.org  Thu Sep 14 16:09:20 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 16:09:20 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v3]
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 incrementally with one additional commit since the last revision:

  Remove tab(s) from comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/40504b2c..24b159d8

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 mchung at openjdk.org  Thu Sep 14 16:13:50 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 14 Sep 2023 16:13:50 GMT
Subject: Integrated: 8315810: Reimplement
 sun.reflect.ReflectionFactory::newConstructorForSerialization with method
 handles
In-Reply-To: 
References: 
Message-ID: 

On Wed, 6 Sep 2023 18:34:29 GMT, Mandy Chung  wrote:

> This reimplements `sun.reflect.ReflectionFactory::newConstructorForSerialization` with method handles.
> 
> This API currently generates the bytecode which fails the verification because `new C; invokespecial A()` where the given class `C` and invoke a no-arg constructor of `C`'s first non-`Serializable` superclass `A` is not a valid operation per the VM specification. VM special cases the classes generated for reflection to skip verification for the constructors generated for serialization and externalization.  This change will allow such VM hack to be removed.
> 
> A `jdk.reflect.useOldSerializableConstructor` system property can be set to use the old implementation in case if customers run into any compatibility issue.   I expect this change has very low compatibility risk.   This system property is undocumented and will be removed in a future release.

This pull request has now been integrated.

Changeset: 5cea53d3
Author:    Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/5cea53d372744ddf1bedaae4667415e6525ef82f
Stats:     151 lines in 10 files changed: 111 ins; 11 del; 29 mod

8315810: Reimplement sun.reflect.ReflectionFactory::newConstructorForSerialization with method handles

Co-authored-by: Chen Liang 
Reviewed-by: rriggs

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

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

From briangoetz at openjdk.org  Thu Sep 14 16:24:41 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 14 Sep 2023 16:24:41 GMT
Subject: RFR: 8315678: Classfile API ConstantPool::entryCount and
 ConstantPool::entryByIndex methods are confusing [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 8 Sep 2023 10:27:28 GMT, Adam Sotona  wrote:

>> Classfile API `ConstantPool::entryCount` and `ConstantPool::entryByIndex` methods are confusing and unsafe to use without knowledge of constant pool specification.
>> This patch renames `ConstantPool::entryCount` to `ConstantPool::size` and adds checks to `ConstantPool::entryByIndex` for invalid or unusable indexes.
>> `ConstantPool` newly extends `Iterable` for simplified user iteration over all pool entries.
>> Range checks for invalid index have been added also to `ConstantPoo::bootstrapMethodEntry` methods and several `@jvms` javadoc tags have been added to pool entries.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base 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:
> 
>  - fixed javac tests
>  - Merge branch 'master' into JDK-8315678-cp-iterable
>  - fixed tests
>  - 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex is confusing

Marked as reviewed by briangoetz (Reviewer).

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 51:

> 49: 
> 50:     /**
> 51:      * {@return the size of the constant pool}

There is still some confusion over the meaning of this method, as "size" (as well as "entry count") could refer to either (a) the number of slots in the constant pool or (b) the number of actual entries in the constant pool, since Constant_{Long,Double} can use two slots.  I agree with the name "size" but we should further clarify that this is the number of slots, but that (a) not all slots necessarily correspond to a valid entry (and therefore entryByIndex may fail) and (b) that iterating the pool may yield fewer entries than the size.

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

PR Review: https://git.openjdk.org/jdk/pull/15567#pullrequestreview-1627302869
PR Review Comment: https://git.openjdk.org/jdk/pull/15567#discussion_r1326210410

From briangoetz at openjdk.org  Thu Sep 14 16:30:41 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 14 Sep 2023 16:30:41 GMT
Subject: RFR: 8313258:
 RuntimeInvisibleTypeAnnotationsAttribute.annotations() API Index out of Bound
 error
In-Reply-To: 
References: 
Message-ID: 

On Thu, 31 Aug 2023 11:09:05 GMT, Adam Sotona  wrote:

> Classfile API suppose to throw IllegalArgumentException in situations where bytecode offset is out of allowed range. Such situation includes invalid offset parsed from a TypeAnnotation as well as from other CodeAttribute attributes.
> 
> This patch throws IAE for invalid bytecode offset when requested Label for the parsed CodeAttribute, so it cover even wider range of cases than mentioned in the bug report.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by briangoetz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15511#pullrequestreview-1627320601

From briangoetz at openjdk.org  Thu Sep 14 16:31:39 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 14 Sep 2023 16:31:39 GMT
Subject: RFR: 8315541: Classfile API TypeAnnotation.TargetInfo factory
 methods accept null labels
In-Reply-To: 
References: 
Message-ID: <-0ViEntMNg0QSyFkVaiY79JUpWnbqCpyNpyA20-l3OY=.394553b5-751b-49c7-98a9-2caba3473441@github.com>

On Tue, 5 Sep 2023 10:59:09 GMT, Adam Sotona  wrote:

> This patch performs null checks in to refuse null labels in  TypeAnnotation.TargetInfo implementations.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by briangoetz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15565#pullrequestreview-1627323409

From briangoetz at openjdk.org  Thu Sep 14 16:37:45 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 14 Sep 2023 16:37:45 GMT
Subject: RFR: 8313452: Improve Classfile API attributes handling safety
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <_xNy2zNDcDmD2jtk-M5DrC3oXCe_rymaibK3PGMNKW0=.22801dac-8a58-406b-be03-443eb882f97a@github.com>

On Wed, 6 Sep 2023 15:03:24 GMT, Adam Sotona  wrote:

>> This PR improved Classfile API attributes handling safety by introduction of attribute stability indicator
>> and by extension of UnknownAttributesOption to more general AttributesProcessingOption.
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   magic moved to Util::isAttributeAllowed and fixed possible NPE

Marked as reviewed by briangoetz (Reviewer).

src/java.base/share/classes/jdk/internal/classfile/AttributeMapper.java line 117:

> 115:      * {@return attribute stability indicator}
> 116:      */
> 117:     AttributeStability attributeStability();

Perhaps the name `stability()` would be better here because all the methods here are about the attribute being described.

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java line 58:

> 56:             attributes.withAttribute(a);
> 57:         }
> 58:     }

The "is allowed" check should always say yes for unbound attributes, and only apply the option for bound attributes.  (You may already have done that, but I wanted to make sure this was captured in the review.)

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 64:

> 62:                 ? ATTRIBUTE_STABILITY_COUNT - attr.attributeMapper().attributeStability().ordinal() > processingOption.ordinal()
> 63:                 : true;
> 64:     }

Ignore earlier comment, looks like you've got this :)

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

PR Review: https://git.openjdk.org/jdk/pull/15101#pullrequestreview-1627325194
PR Review Comment: https://git.openjdk.org/jdk/pull/15101#discussion_r1326230242
PR Review Comment: https://git.openjdk.org/jdk/pull/15101#discussion_r1326233656
PR Review Comment: https://git.openjdk.org/jdk/pull/15101#discussion_r1326235687

From briangoetz at openjdk.org  Thu Sep 14 16:43:50 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 14 Sep 2023 16:43:50 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 8 Sep 2023 10:15:26 GMT, Adam Sotona  wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applied suggested changes from review

src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 184:

> 182:      */
> 183:     ConstantValueEntry readConstantValueEntry(int offset);
> 184: 

I'm not sure that all this additional API surface carries its weight in ClassReader, when each of these methods just called readEntry() and casts to the desired type?  I can see two alternate ways here:

 - Ordinary casts at the use site (worse error handling, but ultimately the same result), or
 -  A single method 

 T readEntry(int pos, Class t)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1326241987

From mchung at openjdk.org  Thu Sep 14 17:12:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 14 Sep 2023 17:12:58 GMT
Subject: RFR: 8316305: Initial buffer size of StackWalker is too small caused
 by JDK-8285447
Message-ID: 

A trivial fix.   [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) intends to change the initial batch size only for a stack walker with an estimated stack depth. For stack walkers without user-supplied estimated stack depth, the initial batch size is changed to 3 which is a bug.  This causes the stack walker to fetch the second batch after walking 2 frames.

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

Commit messages:
 - 8316305: Initial buffer size of StackWalker is too small caused by JDK-8285447

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

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

From bpb at openjdk.org  Thu Sep 14 18:06:39 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 18:06:39 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist
In-Reply-To: <5nGQ3XRmhjhiYRl4Y4IvGQ1Qu24kQmfMoLdNNdOiWPc=.dc573a6c-e552-426d-bb94-e1f2a97e2a9d@github.com>
References: 
 
 <5nGQ3XRmhjhiYRl4Y4IvGQ1Qu24kQmfMoLdNNdOiWPc=.dc573a6c-e552-426d-bb94-e1f2a97e2a9d@github.com>
Message-ID: 

On Tue, 12 Sep 2023 06:27:42 GMT, Alan Bateman  wrote:

>> src/java.base/windows/native/libjava/WinNTFileSystem_md.c line 479:
>> 
>>> 477:     if (access == java_io_FileSystem_ACCESS_READ ||
>>> 478:         access == java_io_FileSystem_ACCESS_EXECUTE) {
>>> 479:         return _waccess(pathbuf, 0) == 0 ? enable : JNI_FALSE;
>> 
>> Here `enable` is returned for backward compatibility, but per the specification it seems that `JNI_TRUE` should be returned instead.
>
> I don't think this is right, at least it doesn't work with ACLs and file system security so it can't test if the file is executable. Also I have a concern about mixing win32 and C runtime functions here.  The main issue with these setXXX methods is that don't map to DOS file attributes or ACL based security so they will need to fail for some cases.

If this code does not interact with ACL-based security, then it's not clear to me that there's anything to be done here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15673#discussion_r1326342392

From rriggs at openjdk.org  Thu Sep 14 18:16:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Sep 2023 18:16:40 GMT
Subject: RFR: 8316160: Remove
 sun.misc.Unsafe.{shouldBeInitialized,ensureClassInitialized}
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 09:50:35 GMT, Alan Bateman  wrote:

> Unsafe.{shouldBeInitialized,ensureClassInitialized} are deprecated for removal since JDK 15. It's time to remove them. Lookup.ensureInitialized(Class) was added in Java 15 as a standard API to ensure that an accessible class is initialized. 
> 
> A search of 175973022 classes in 484751 artifacts found:
> - 23 usages of Unsafe.shouldBeInitialized, of which 8 are unique
> - 121 usages of Unsafe.ensureClassInitialized, of which 31 are unique
> 
> Not a lot of usage, many of the usages seem to be code compiled to older releases.

Times up.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15707#pullrequestreview-1627502051

From mchung at openjdk.org  Thu Sep 14 18:24:38 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 14 Sep 2023 18:24:38 GMT
Subject: RFR: 8316160: Remove
 sun.misc.Unsafe.{shouldBeInitialized,ensureClassInitialized}
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 09:50:35 GMT, Alan Bateman  wrote:

> Unsafe.{shouldBeInitialized,ensureClassInitialized} are deprecated for removal since JDK 15. It's time to remove them. Lookup.ensureInitialized(Class) was added in Java 15 as a standard API to ensure that an accessible class is initialized. 
> 
> A search of 175973022 classes in 484751 artifacts found:
> - 23 usages of Unsafe.shouldBeInitialized, of which 8 are unique
> - 121 usages of Unsafe.ensureClassInitialized, of which 31 are unique
> 
> Not a lot of usage, many of the usages seem to be code compiled to older releases.

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15707#pullrequestreview-1627514371

From asotona at openjdk.org  Thu Sep 14 18:30:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 18:30:47 GMT
Subject: Integrated: 8315541: Classfile API TypeAnnotation.TargetInfo factory
 methods accept null labels
In-Reply-To: 
References: 
Message-ID: 

On Tue, 5 Sep 2023 10:59:09 GMT, Adam Sotona  wrote:

> This patch performs null checks in to refuse null labels in  TypeAnnotation.TargetInfo implementations.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: c7d306c6
Author:    Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/c7d306c65c5ed26839b323f3dfc7e5b68e5adaa1
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8315541: Classfile API TypeAnnotation.TargetInfo factory methods accept null labels

Reviewed-by: briangoetz

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

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

From asotona at openjdk.org  Thu Sep 14 18:31:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 18:31:51 GMT
Subject: Integrated: 8313258:
 RuntimeInvisibleTypeAnnotationsAttribute.annotations() API Index out of Bound
 error
In-Reply-To: 
References: 
Message-ID: 

On Thu, 31 Aug 2023 11:09:05 GMT, Adam Sotona  wrote:

> Classfile API suppose to throw IllegalArgumentException in situations where bytecode offset is out of allowed range. Such situation includes invalid offset parsed from a TypeAnnotation as well as from other CodeAttribute attributes.
> 
> This patch throws IAE for invalid bytecode offset when requested Label for the parsed CodeAttribute, so it cover even wider range of cases than mentioned in the bug report.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 6d47fc6d
Author:    Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/6d47fc6d5b81d6764af322cc17653683f79a89de
Stats:     13 lines in 2 files changed: 13 ins; 0 del; 0 mod

8313258: RuntimeInvisibleTypeAnnotationsAttribute.annotations() API Index out of Bound error

Reviewed-by: briangoetz

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

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

From asotona at openjdk.org  Thu Sep 14 18:32:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 18:32:50 GMT
Subject: RFR: 8315678: Classfile API ConstantPool::entryCount and
 ConstantPool::entryByIndex methods are confusing [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 14 Sep 2023 16:17:35 GMT, Brian Goetz  wrote:

>> Adam Sotona has updated the pull request with a new target base 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:
>> 
>>  - fixed javac tests
>>  - Merge branch 'master' into JDK-8315678-cp-iterable
>>  - fixed tests
>>  - 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex is confusing
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 51:
> 
>> 49: 
>> 50:     /**
>> 51:      * {@return the size of the constant pool}
> 
> There is still some confusion over the meaning of this method, as "size" (as well as "entry count") could refer to either (a) the number of slots in the constant pool or (b) the number of actual entries in the constant pool, since Constant_{Long,Double} can use two slots.  I agree with the name "size" but we should further clarify that this is the number of slots, but that (a) not all slots necessarily correspond to a valid entry (and therefore entryByIndex may fail) and (b) that iterating the pool may yield fewer entries than the size.

I'll mention it in the javadoc

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15567#discussion_r1326368849

From asotona at openjdk.org  Thu Sep 14 18:32:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 18:32:52 GMT
Subject: Integrated: 8315678: Classfile API ConstantPool::entryCount and
 ConstantPool::entryByIndex methods are confusing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 5 Sep 2023 14:18:08 GMT, Adam Sotona  wrote:

> Classfile API `ConstantPool::entryCount` and `ConstantPool::entryByIndex` methods are confusing and unsafe to use without knowledge of constant pool specification.
> This patch renames `ConstantPool::entryCount` to `ConstantPool::size` and adds checks to `ConstantPool::entryByIndex` for invalid or unusable indexes.
> `ConstantPool` newly extends `Iterable` for simplified user iteration over all pool entries.
> Range checks for invalid index have been added also to `ConstantPoo::bootstrapMethodEntry` methods and several `@jvms` javadoc tags have been added to pool entries.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: ca747f09
Author:    Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/ca747f09b67071938fb101ce61742c56305af341
Stats:     140 lines in 40 files changed: 70 ins; 20 del; 50 mod

8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex methods are confusing

Reviewed-by: briangoetz

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

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

From asotona at openjdk.org  Thu Sep 14 18:58:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 18:58:51 GMT
Subject: RFR: 8313452: Improve Classfile API attributes handling safety
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR improved Classfile API attributes handling safety by introduction of attribute stability indicator
> and by extension of UnknownAttributesOption to more general AttributesProcessingOption.

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

  renamed AttributeMapper::attributeStability to stability

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15101/files
  - new: https://git.openjdk.org/jdk/pull/15101/files/392ba560..1105033c

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

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

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

From asotona at openjdk.org  Thu Sep 14 18:58:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 18:58:56 GMT
Subject: Integrated: 8313452: Improve Classfile API attributes handling safety
In-Reply-To: 
References: 
Message-ID: 

On Tue, 1 Aug 2023 08:36:01 GMT, Adam Sotona  wrote:

> This PR improved Classfile API attributes handling safety by introduction of attribute stability indicator
> and by extension of UnknownAttributesOption to more general AttributesProcessingOption.

This pull request has now been integrated.

Changeset: b2e91060
Author:    Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/b2e91060db82a13e993227f538c8d54b41a9796b
Stats:     490 lines in 10 files changed: 382 ins; 32 del; 76 mod

8313452: Improve Classfile API attributes handling safety

Reviewed-by: briangoetz

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

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

From asotona at openjdk.org  Thu Sep 14 18:58:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 18:58:53 GMT
Subject: RFR: 8313452: Improve Classfile API attributes handling safety
 [v3]
In-Reply-To: <_xNy2zNDcDmD2jtk-M5DrC3oXCe_rymaibK3PGMNKW0=.22801dac-8a58-406b-be03-443eb882f97a@github.com>
References: 
 
 <_xNy2zNDcDmD2jtk-M5DrC3oXCe_rymaibK3PGMNKW0=.22801dac-8a58-406b-be03-443eb882f97a@github.com>
Message-ID: 

On Thu, 14 Sep 2023 16:30:21 GMT, Brian Goetz  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   magic moved to Util::isAttributeAllowed and fixed possible NPE
>
> src/java.base/share/classes/jdk/internal/classfile/AttributeMapper.java line 117:
> 
>> 115:      * {@return attribute stability indicator}
>> 116:      */
>> 117:     AttributeStability attributeStability();
> 
> Perhaps the name `stability()` would be better here because all the methods here are about the attribute being described.

Renamed, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15101#discussion_r1326391762

From duke at openjdk.org  Thu Sep 14 19:25:50 2023
From: duke at openjdk.org (Soumadipta Roy)
Date: Thu, 14 Sep 2023 19:25:50 GMT
Subject: Integrated: 8315683: Parallelize
 java/util/concurrent/tck/JSR166TestCase.java
In-Reply-To: 
References: 
Message-ID: 

On Thu, 7 Sep 2023 13:55:18 GMT, Soumadipta Roy  wrote:

> This test is running in tier1, and takes about 400 seconds to complete. Thus, it drags the execution time of tier1 on large machines. The commit includes changing the sequential run of test cases in java/util/concurrent/tck/JSR166TestCase.java to the best possible combination of parallelization to reduce the total runtime of the overall test and causing least possible change to user and system times. The below comparison shows existing and newer combinations of parallelizations:
> 
> * before                           : **200.64s user 20.94s system 204% cpu 1:48.47 total**
> * fully parallel                  : **308.84s user 23.75s system 479% cpu 1:09.42 total**
> * default-details-tck       : **244.69s user 22.03s system 314% cpu 1:24.94 total**
> * default-fjp_details-others : **260.12s user 24.47s system 404% cpu 1:10.31 total**
> 
> Based on the comparison above, the fourth combination has a result very close to full parallelization and at the same time having the least deviation of system and user times among the newer combinations. Hence the commit includes the changes corresponding to the fourth combination.

This pull request has now been integrated.

Changeset: 44152616
Author:    Soumadipta Roy 
Committer: Martin Buchholz 
URL:       https://git.openjdk.org/jdk/commit/4415261688dc258b6d254668bcf8818c61cc65ea
Stats:     34 lines in 1 file changed: 27 ins; 4 del; 3 mod

8315683: Parallelize java/util/concurrent/tck/JSR166TestCase.java

Reviewed-by: martin, shade

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

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

From asotona at openjdk.org  Thu Sep 14 20:01:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 20:01:52 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v13]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 14 Sep 2023 16:38:36 GMT, Brian Goetz  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied suggested changes from review
>
> src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 184:
> 
>> 182:      */
>> 183:     ConstantValueEntry readConstantValueEntry(int offset);
>> 184: 
> 
> I'm not sure that all this additional API surface carries its weight in ClassReader, when each of these methods just called readEntry() and casts to the desired type?  I can see two alternate ways here:
> 
>  - Ordinary casts at the use site (worse error handling, but ultimately the same result), or
>  -  A single method 
> 
>  T readEntry(int pos, Class t)

We need at least ` T readEntry(int pos, Class t)` to throw `ConstantPoolException` instead of `ClassCastException` from broken entries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1326453583

From asotona at openjdk.org  Thu Sep 14 20:14:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 20:14:33 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v14]
In-Reply-To: 
References: 
Message-ID: 

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> 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 233 commits:

 - reducing ClassReader API footprint
 - fixed ConstantWriter
 - Merge branch 'master' into JDK-8294969
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java
 - applied suggested changes from review
 - minor patches
 - Merge branch 'master' into JDK-8294969
 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
 - fixed code printing and ConstantPoolException reporting indoex
 - added DydnamicConstantPoolEntry::bootstrapMethodIndex
   fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
 - ... and 223 more: https://git.openjdk.org/jdk/compare/b2e91060...938571fc

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=13
  Stats: 3756 lines in 29 files changed: 919 ins; 1778 del; 1059 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From bchristi at openjdk.org  Thu Sep 14 20:45:40 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 14 Sep 2023 20:45:40 GMT
Subject: RFR: 8316305: Initial buffer size of StackWalker is too small
 caused by JDK-8285447
In-Reply-To: 
References: 
Message-ID: 

On Thu, 14 Sep 2023 17:06:53 GMT, Mandy Chung  wrote:

> A trivial fix.   [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) intends to change the initial batch size only for a stack walker with an estimated stack depth. For stack walkers without user-supplied estimated stack depth, the initial batch size is changed to 3 which is a bug.  This causes the stack walker to fetch the second batch after walking 2 frames.

src/java.base/share/classes/java/lang/StackStreamFactory.java line 544:

> 542:                 return walker.estimateDepth() == 0
> 543:                         ? SMALL_BATCH
> 544:                         : Math.min(walker.estimateDepth() + RESERVED_ELEMENTS, LARGE_BATCH_SIZE);

Without the
`Math.max(walker.estimateDepth()+RESERVED_ELEMENTS, MIN_BATCH_SIZE)`
for estimateDepth = 1, I believe this will now return 2, where previously it returned 3.
Is that OK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15749#discussion_r1326495665

From mchung at openjdk.org  Thu Sep 14 21:20:39 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 14 Sep 2023 21:20:39 GMT
Subject: RFR: 8316305: Initial buffer size of StackWalker is too small
 caused by JDK-8285447
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 14 Sep 2023 20:42:57 GMT, Brent Christian  wrote:

>> A trivial fix.   [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) intends to change the initial batch size only for a stack walker with an estimated stack depth. For stack walkers without user-supplied estimated stack depth, the initial batch size is changed to 3 which is a bug.  This causes the stack walker to fetch the second batch after walking 2 frames.
>
> src/java.base/share/classes/java/lang/StackStreamFactory.java line 544:
> 
>> 542:                 return walker.estimateDepth() == 0
>> 543:                         ? SMALL_BATCH
>> 544:                         : Math.min(walker.estimateDepth() + RESERVED_ELEMENTS, LARGE_BATCH_SIZE);
> 
> Without the
> `Math.max(walker.estimateDepth()+RESERVED_ELEMENTS, MIN_BATCH_SIZE)`
> for estimateDepth = 1, I believe this will now return 2, where previously it returned 3.
> Is that OK?

yes as it's asked by the user.  It will fetch the second batch if it walks more than 1 frame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15749#discussion_r1326524419

From bchristi at openjdk.org  Thu Sep 14 21:28:37 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 14 Sep 2023 21:28:37 GMT
Subject: RFR: 8316305: Initial buffer size of StackWalker is too small
 caused by JDK-8285447
In-Reply-To: 
References: 
Message-ID: 

On Thu, 14 Sep 2023 17:06:53 GMT, Mandy Chung  wrote:

> A trivial fix.   [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) intends to change the initial batch size only for a stack walker with an estimated stack depth. For stack walkers without user-supplied estimated stack depth, the initial batch size is changed to 3 which is a bug.  This causes the stack walker to fetch the second batch after walking 2 frames.

Marked as reviewed by bchristi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15749#pullrequestreview-1627775967

From bchristi at openjdk.org  Thu Sep 14 21:28:39 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 14 Sep 2023 21:28:39 GMT
Subject: RFR: 8316305: Initial buffer size of StackWalker is too small
 caused by JDK-8285447
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 14 Sep 2023 21:15:48 GMT, Mandy Chung  wrote:

>> src/java.base/share/classes/java/lang/StackStreamFactory.java line 544:
>> 
>>> 542:                 return walker.estimateDepth() == 0
>>> 543:                         ? SMALL_BATCH
>>> 544:                         : Math.min(walker.estimateDepth() + RESERVED_ELEMENTS, LARGE_BATCH_SIZE);
>> 
>> Without the
>> `Math.max(walker.estimateDepth()+RESERVED_ELEMENTS, MIN_BATCH_SIZE)`
>> for estimateDepth = 1, I believe this will now return 2, where previously it returned 3.
>> Is that OK?
>
> yes as it's asked by the user.  It will fetch the second batch if it walks more than 1 frame.

Sounds good, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15749#discussion_r1326532469

From lancea at openjdk.org  Thu Sep 14 21:33:38 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 21:33:38 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.

This makes sense to remove.

Joe is on holiday so please wait for his input as there are some additional constants that may also be removed.

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15692#pullrequestreview-1627780880

From bpb at openjdk.org  Thu Sep 14 22:01:55 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 22:01:55 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java leaves
 test files behind
Message-ID: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>

Add a `finally` block to delete the created files.

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

Commit messages:
 - 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java leaves test files behind

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

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

From lancea at openjdk.org  Thu Sep 14 22:10:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 22:10:39 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: 

On Thu, 14 Sep 2023 21:53:30 GMT, Brian Burkhalter  wrote:

> Add a `finally` block to delete the created files.

Given this is a small test, perhaps it would be worthwhile to convert to Junit as part of your cleanup

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

PR Review: https://git.openjdk.org/jdk/pull/15757#pullrequestreview-1627818889

From jlu at openjdk.org  Thu Sep 14 22:22:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 14 Sep 2023 22:22:50 GMT
Subject: Integrated: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: 
References: 
Message-ID: 

On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu  wrote:

> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
> 
> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
> 
> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
> 
> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
> 
> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

This pull request has now been integrated.

Changeset: b55e418a
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/b55e418a077791b39992042411cde97f68dc39fe
Stats:     28964 lines in 488 files changed: 12 ins; 0 del; 28952 mod

8301991: Convert l10n properties resource bundles to UTF-8 native

Reviewed-by: naoto

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

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

From psandoz at openjdk.org  Thu Sep 14 23:06:53 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 14 Sep 2023 23:06:53 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v36]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 13 Sep 2023 23:02:21 GMT, Srinivas Vamsi Parasa  wrote:

> Could you please have a look at the changes in `DualPivotQuicksort.java` and provide your feedback?

I agree that is much cleaner, glad that worked out. That neatly covers multiple element types and Java-based insertion sort algorithms (although I don't know why we need two since mixed insertion effectively embeds the other but we don't need to address that here).

I recommend embedding the functional interfaces next to the associated methods, rather than as auxiliary classes, and also adding `@ForceInline` on `arraySort`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1720264496

From bpb at openjdk.org  Fri Sep 15 00:02:38 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 00:02:38 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
Message-ID: <5uKa3kyld4gEQQNby5yqZNf_no53Gco9dG4sJclVQ-Q=.e8700cb9-d4a3-426f-a19b-c3d01d6b5e8e@github.com>

On Thu, 14 Sep 2023 22:08:02 GMT, Lance Andersen  wrote:

> Given this is a small test, perhaps it would be worthwhile to convert to Junit as part of your cleanup

It was not completely obvious at first how to do this, but after some investigation, I think it is feasible.

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

PR Comment: https://git.openjdk.org/jdk/pull/15757#issuecomment-1720301549

From dholmes at openjdk.org  Fri Sep 15 00:38:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 15 Sep 2023 00:38:56 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v3]
In-Reply-To: 
References: 
 <2rTLX86raFjJBNOlUysJoxGB8UaGLH7szSa_EOmXEDE=.e545fc08-9354-4173-b88f-b8173c3878b7@github.com>
 
 
 
Message-ID: 

On Thu, 14 Sep 2023 13:29:48 GMT, Alan Bateman  wrote:

>> Yes but TIMED and SUSPENDED are not alike. I assume SUSPENDED is a stand-alone bit because you can be in various states and suspended at the same time. But TIMED isn't like that.
>
>> Yes but TIMED and SUSPENDED are not alike. I assume SUSPENDED is a stand-alone bit because you can be in various states and suspended at the same time. But TIMED isn't like that.
> 
> The SUSPENDED bit can only be set when the virtual thread is unmounted, so limited to the RUNNABLE and PARKED states at this time.
> 
> The intention with TIMED was that it could be OR'ed with PARKING, PARKED or PINNED to qualify that they are timed rather than untimed. It wouldn't make sense in other states.

What is TIMED PINNING? 

To me TIMED_X are a specific set of states and there are not enough of them to consider TIMED to be a bit that can be applied to any state X.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1326652913

From pminborg at openjdk.org  Fri Sep 15 05:46:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 15 Sep 2023 05:46:49 GMT
Subject: Integrated: 8316190: Improve MemorySegment::toString
In-Reply-To: 
References: 
Message-ID: 

On Thu, 14 Sep 2023 12:01:29 GMT, Per Minborg  wrote:

> This PR proposes to improve the MemorySegment::toString to reduce cluttering and add missing comas.

This pull request has now been integrated.

Changeset: 8dc2d928
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/8dc2d9280e9d100374a6e33b5d32905bc909a52d
Stats:     26 lines in 3 files changed: 24 ins; 0 del; 2 mod

8316190: Improve MemorySegment::toString

Reviewed-by: rriggs

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

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

From jpai at openjdk.org  Fri Sep 15 05:52:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Sep 2023 05:52:39 GMT
Subject: RFR: 8316160: Remove
 sun.misc.Unsafe.{shouldBeInitialized,ensureClassInitialized}
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 09:50:35 GMT, Alan Bateman  wrote:

> Unsafe.{shouldBeInitialized,ensureClassInitialized} are deprecated for removal since JDK 15. It's time to remove them. Lookup.ensureInitialized(Class) was added in Java 15 as a standard API to ensure that an accessible class is initialized. 
> 
> A search of 175973022 classes in 484751 artifacts found:
> - 23 usages of Unsafe.shouldBeInitialized, of which 8 are unique
> - 121 usages of Unsafe.ensureClassInitialized, of which 31 are unique
> 
> Not a lot of usage, many of the usages seem to be code compiled to older releases.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15707#pullrequestreview-1628231574

From pminborg at openjdk.org  Fri Sep 15 06:06:18 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 15 Sep 2023 06:06:18 GMT
Subject: RFR: 8316196: VarHandleSegmentViewBase::newIllegalArg... to use
 hexadecimal form [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to use hexadecimal formatting for raw addresses in `VarHandleSegmentViewBase`.

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

 - Merge branch 'master' into vh-hex
 - VarHandleSegmentViewBase::newIllegalArg... to use hexadecimal form

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15742/files
  - new: https://git.openjdk.org/jdk/pull/15742/files/c4d1f8d1..81381cdb

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

  Stats: 35561 lines in 636 files changed: 4745 ins; 1495 del; 29321 mod
  Patch: https://git.openjdk.org/jdk/pull/15742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15742/head:pull/15742

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

From alanb at openjdk.org  Fri Sep 15 06:37:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Sep 2023 06:37:47 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v3]
In-Reply-To: 
References: 
 <2rTLX86raFjJBNOlUysJoxGB8UaGLH7szSa_EOmXEDE=.e545fc08-9354-4173-b88f-b8173c3878b7@github.com>
 
 
 
 
Message-ID: 

On Fri, 15 Sep 2023 00:36:10 GMT, David Holmes  wrote:

> What is TIMED PINNING?

LockSupport.parkNanos when the carrier can't be released due to monitor or native frame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1326860516

From simone.bordet at gmail.com  Fri Sep 15 07:00:19 2023
From: simone.bordet at gmail.com (Simone Bordet)
Date: Fri, 15 Sep 2023 09:00:19 +0200
Subject: Java 21 clinit deadlock
In-Reply-To: <9eb34d59-f00d-4a73-9eaf-5353b4ba5838@oracle.com>
References: 
 <77f901c7-5bb8-4703-8c64-b331913516b6@oracle.com>
 
 
 
 
 <9eb34d59-f00d-4a73-9eaf-5353b4ba5838@oracle.com>
Message-ID: 

David,

On Thu, Sep 14, 2023 at 4:33?AM David Holmes  wrote:
> I've created a draft PR here:
>
> https://github.com/openjdk/jdk/pull/15732
>
> can you apply that patch, build and re-test? Hopefully that will show
> which thread is doing the missing initialization.

We have attached the logs to the pull request above.

Seems like a classic deadlock:

'[8.061s][debug][class,init] Thread ForkJoinPool-1-worker-1 is
initializing org.eclipse.jetty.http.HttpFields'.
...
'[8.113s][debug][class,init] Thread ForkJoinPool-1-worker-2 is
initializing org.eclipse.jetty.http.MutableHttpFields'.
'[8.113s][debug][class,init] Thread ForkJoinPool-1-worker-2 waiting
for initialization of org.eclipse.jetty.http.HttpFields by thread
ForkJoinPool-1-worker-1'.
...
'[8.117s][debug][class,init] Thread ForkJoinPool-1-worker-1
recursively initializing org.eclipse.jetty.http.HttpFields'.
'[8.117s][debug][class,init] Thread ForkJoinPool-1-worker-1 waiting
for initialization of org.eclipse.jetty.http.MutableHttpFields by
thread ForkJoinPool-1-worker-2'.

It is peculiar that we already get this deadlock for the same classes.
Perhaps we are using a pattern in the code that makes it more likely to happen?

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From duke at openjdk.org  Fri Sep 15 07:39:52 2023
From: duke at openjdk.org (iaroslavski)
Date: Fri, 15 Sep 2023 07:39:52 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v36]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 14 Sep 2023 23:03:22 GMT, Paul Sandoz  wrote:

> That neatly covers multiple element types and Java-based insertion sort algorithms (although I don't know why we need two since mixed insertion effectively embeds the other).

@PaulSandoz There are two insertion sorts in DPQ: mixedInsertion() sort is used to sort all non-leftmost parts without left range check in the inner loop, and insertionSort() is used (only once) to sort the leftmost part (classical implementation).

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1720818647

From anleonar at redhat.com  Fri Sep 15 08:09:06 2023
From: anleonar at redhat.com (Andrew Leonard)
Date: Fri, 15 Sep 2023 09:09:06 +0100
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
Message-ID: 

Hi,

jrt-fs.jar is the only jar that is not built (or re-built) with the "Build
JDK", and I was wondering why?
To fully benefit from reproducible builds, would it not be more beneficial
to re-build it after "Build JDK" generation? Thereby ensuring all java code
is built based on the latest compiler sources, and also disconnect the
"reproducibility" of the JDK image from the BootJDK chosen.

We can effectively achieve this now by doing a "bootcycle-images" build,
which basically does the build twice. Would that be the best way forward,
or should we simply add re-building of jrt-fs.jar after "Build JDK" is
generated?

Thoughts?

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

From Alan.Bateman at oracle.com  Fri Sep 15 08:16:54 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 15 Sep 2023 09:16:54 +0100
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: 
References: 
Message-ID: <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>

On 15/09/2023 09:09, Andrew Leonard wrote:
> Hi,
>
> jrt-fs.jar is the only jar that is not built (or re-built) with the 
> "Build JDK", and I was wondering why?
>

The JAR file contains the "jrt" file system provider for the runtime.? 
IDE or other tools running on JDK 8/11/etc. need to be able to create a 
FileSystem to access the classes/resources in the run-time image. These 
classes are loaded from that JAR file.

-Alan

From prappo at openjdk.org  Fri Sep 15 08:31:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 15 Sep 2023 08:31:38 GMT
Subject: RFR: 8316187: Modernize an example in StringTokenizer
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 22:55:00 GMT, Naoto Sato  wrote:

>> This modernizes an example to use the extended for-statement introduced in JDK 1.5.
>> 
>> I understand that StringTokenizer is a legacy class. But legacy or not, a class shouldn't promote older constructs when newer fit better. Especially when advising on preferred alternatives to itself.
>> 
>> That said, I wouldn't go as far as to use `var` anywhere in that example: JDK 10, which introduced `var`, might still be relatively new to some. Nor would I inline the call to `String.split` in the for-statement to dispense with the `String[] result` variable: I reckon it's good for a reader unfamiliar with `String.split` to see the type it returns.
>> 
>> Perhaps one additional thing to ponder is this: we could either add `@see` to point to `String.split` or make the whole example a `@snippet`, which `@link`s code to the definition of `String.split`.
>
> Marked as reviewed by naoto (Reviewer).

Thanks for your review, @naotoj. I found a few more similar cases in the related classes. Do you think I can add them to this PR, change the title appropriately, and get it re-reviewed, or would you prefer if I create a new PR?


diff --git a/src/java.base/share/classes/java/text/DateFormat.java b/src/java.base/share/classes/java/text/DateFormat.java
index ed6356e3fd8..e6760a6bca6 100644
--- a/src/java.base/share/classes/java/text/DateFormat.java
+++ b/src/java.base/share/classes/java/text/DateFormat.java
@@ -85,8 +85,8 @@
  * 

  * {@snippet lang=java :
  * DateFormat df = DateFormat.getDateInstance();
- * for (int i = 0; i < myDate.length; ++i) {
- *     output.println(df.format(myDate[i]) + "; ");
+ * for (Date d : dates) {
+ *     output.println(df.format(d) + "; ");
  * }
  * }
  * 

diff --git a/src/java.base/share/classes/java/text/NumberFormat.java b/src/java.base/share/classes/java/text/NumberFormat.java
index 4628870bbdb..ff369ee6682 100644
--- a/src/java.base/share/classes/java/text/NumberFormat.java
+++ b/src/java.base/share/classes/java/text/NumberFormat.java
@@ -82,8 +82,8 @@
  * 

  * {@snippet lang=java :
  * NumberFormat nf = NumberFormat.getInstance();
- * for (int i = 0; i < myNumber.length; ++i) {
- *     output.println(nf.format(myNumber[i]) + "; ");
+ * for (var n : numbers) {
+ *     output.println(nf.format(n) + "; ");
  * }
  * }
  * 


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

PR Comment: https://git.openjdk.org/jdk/pull/15716#issuecomment-1720884886

From alanb at openjdk.org  Fri Sep 15 09:12:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Sep 2023 09:12:48 GMT
Subject: Integrated: 8316160: Remove
 sun.misc.Unsafe.{shouldBeInitialized,ensureClassInitialized}
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 09:50:35 GMT, Alan Bateman  wrote:

> Unsafe.{shouldBeInitialized,ensureClassInitialized} are deprecated for removal since JDK 15. It's time to remove them. Lookup.ensureInitialized(Class) was added in Java 15 as a standard API to ensure that an accessible class is initialized. 
> 
> A search of 175973022 classes in 484751 artifacts found:
> - 23 usages of Unsafe.shouldBeInitialized, of which 8 are unique
> - 121 usages of Unsafe.ensureClassInitialized, of which 31 are unique
> 
> Not a lot of usage, many of the usages seem to be code compiled to older releases.

This pull request has now been integrated.

Changeset: 25f32f35
Author:    Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/25f32f353830fddd4883f0fd191303b9dd9898c7
Stats:     36 lines in 1 file changed: 0 ins; 36 del; 0 mod

8316160: Remove sun.misc.Unsafe.{shouldBeInitialized,ensureClassInitialized}

Reviewed-by: rriggs, mchung, jpai

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

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

From aturbanov at openjdk.org  Fri Sep 15 09:20:41 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 15 Sep 2023 09:20:41 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0
In-Reply-To: 
References: 
Message-ID: <0lMo5h6kK2P953OpxrumtOCXt1APUmm9_61TITb2810=.e77618f2-2e4e-49fe-b434-5df2de942061@github.com>

On Wed, 13 Sep 2023 20:15:09 GMT, Naoto Sato  wrote:

> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Consonant Break specified in the latest Unicode Annex #29 ("Unicode Text Segmentation") is included. A corresponding CSR has also been drafted.

make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java line 65:

> 63:  *    args[3...]: Names of the property to generate the conditions
> 64:  */
> 65: public class  GenerateExtraProperties {

Suggestion:

public class GenerateExtraProperties {

make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java line 118:

> 116:         if (r.start == r.last) {
> 117:             return (" ".repeat(12) + "cp == 0x" + toHexString(r.start));
> 118:         } else  if (r.start == r.last - 1) {

Suggestion:

        } else if (r.start == r.last - 1) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1327033148
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1327033517

From duke at openjdk.org  Fri Sep 15 09:38:40 2023
From: duke at openjdk.org (iaroslavski)
Date: Fri, 15 Sep 2023 09:38:40 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>
 
Message-ID: <89P3XIAl6Js9CSjf3ZQfpBH3fDgaighmiU-L8st9Ong=.1ef7343e-bfc0-419e-97cf-8fc1f95b80c6@github.com>

On Wed, 30 Aug 2023 10:55:48 GMT, Laurent Bourg?s  wrote:

>> * 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:
> 
>   updated comments (v23.08)

Hi team,

@AlanBateman Alan,
Are there other questions/comments regarding to Radix sort?

Reviewers,
@rose00 John Rose
@mbreinhold Mark Reinhold
@pavelrappo Pavel Rappo
@theRealAph Andrew Haley
@schlosna David Schlosnagle
@PaulSandoz Paul Sandoz
@vnkozlov Vladimir Kozlov
@erikj79 Erik Joelsson
@jatin-bhateja Jatin Bhateja
@sviswa7 Sandhya Viswanathan
@vamsi-parasa Srinivas Vamsi Parasa

We have two improvements of sorting: algorithmic approach (this PR) and based on AVX512 (https://github.com/openjdk/jdk/pull/14227).
Both changes are important, could you please find time to look at this PR?

Thank you,
Vladimir

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1720975896

From asotona at openjdk.org  Fri Sep 15 09:42:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Sep 2023 09:42:24 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v15]
In-Reply-To: 
References: 
Message-ID: 

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

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

  fixed TestClassNameWarning test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/938571fc..ae3b25bf

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

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

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

From prappo at openjdk.org  Fri Sep 15 09:43:43 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 15 Sep 2023 09:43:43 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v7]
In-Reply-To: 
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
 
 
 
 
Message-ID: 

On Thu, 17 Aug 2023 09:23:30 GMT, Pavel Rappo  wrote:

>>> These benchmarks are all small arrays. We need to check for possible regressions here. 
>> 
>> Sorry, all large arrays. I suspect that the average-length sort is not represented.
>> 
>>> Also, I'm rather concerned that we might lose the data from this PR.
>> 
>> How does keep alive work? Will the data from that external web site still be here for the reader in 15 years' time?
>
>> How does keep alive work? Will the data from that external web site still be here for the reader in 15 years' time?
> 
> Hm... I thought that at least full webrevs are stored somewhere on https://cr.openjdk.org/. Turns out they aren't. They are stored on https://openjdk.github.io/cr/.
> 
> Okay, a cheap thing to do *now* is to ask the Web Archive to store it, which I just did:
> 
>   * https://web.archive.org/web/20230817091712/https://openjdk.github.io/cr/?repo=jdk&pr=13568&range=06
>   * https://web.archive.org/web/20230817091943/https://github.com/openjdk/jdk/compare/0f51e6326373ff7d4a4d9a0e3a2788401f73405d...f7f7e11adf9984ee1ce316e3e36f5e351b49bb97.diff
>   * https://web.archive.org/web/20230817092146/https://github.com/openjdk/jdk/pull/13568

> @pavelrappo Pavel Rappo

Vladimir, please do not consider me a reviewer. I'm merely a passer-by: I didn't review a single line of this PR, nor do I have expertise to do so.

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1720983110

From duke at openjdk.org  Fri Sep 15 12:38:51 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Fri, 15 Sep 2023 12:38:51 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 14 Aug 2023 20:23:13 GMT, Aleksey Shipilev  wrote:

>> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
>> 
>> final int size = (1 << 30) + 1;
>> final List list = new ArrayList<>(size);
>> for (int i = 0; i < size; ++i)
>>     list.add((byte) 0);
>> Collections.rotate(list, size - 1);
>> 
>> Output:
>> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
>> 
>> In that case private method `Collections.rotate1` will be called. And the line:
>> `i += distance;`
>> will cause overflow. I fixed this method and wrote a test for it.
>> 
>> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
>> 
>> Kindly ask you to raise a bug.
>
> Submitted: [JDK-8314236](https://bugs.openjdk.org/browse/JDK-8314236)
> 
> Please change the PR synopsis to: "8314236: Overflow in Collections.rotate".
> 
> Also go to https://github.com/nikita-sakharin/jdk/actions, and enable testing workflows.

Aleksey Shipil?v (@shipilev), Stuart Marks (@stuart-marks), thank you for your approvals. Since both reviewers approved the PR, it is ready to be integrated.

I have already executed `/integrate` command. Now I am awaiting one of you to execute `/sponsor`  command. So I kindly ask you to do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/15270#issuecomment-1721204139

From dl at openjdk.org  Fri Sep 15 12:43:44 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 15 Sep 2023 12:43:44 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v33]
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 79 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Revert Unsafe; reduce signal stalls
 - Merge branch 'openjdk:master' into JDK-8288899
 - Strengthen translation of getAndX atomics; revert or adapt FJP accordingly
 - Merge branch 'openjdk:master' into JDK-8288899
 - Force more orderings; improve diagnostics
 - Simplify signalling
 - Always help terminate when stopping
 - Merge branch 'openjdk:master' into JDK-8288899
 - Use non-recursive tasks in close tests
 - ... and 69 more: https://git.openjdk.org/jdk/compare/3631c553...b9792f67

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/d04ce80f..b9792f67

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

  Stats: 37363 lines in 768 files changed: 6088 ins; 1570 del; 29705 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 jvernee at openjdk.org  Fri Sep 15 12:52:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 15 Sep 2023 12:52:41 GMT
Subject: RFR: 8316196: VarHandleSegmentViewBase::newIllegalArg... to use
 hexadecimal form [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 06:06:18 GMT, Per Minborg  wrote:

>> This PR proposes to use hexadecimal formatting for raw addresses in `VarHandleSegmentViewBase`.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into vh-hex
>  - VarHandleSegmentViewBase::newIllegalArg... to use hexadecimal form

There are many other places where we print addresses, for instance a in `LayoutPath`, when slicing a segment, or when reading an address with a layout from a segment to name a few. We should fix all of them so that we don't create an inconsistent way of printing addresses.

There are also cases which are not present in mainline, like the UOE throw from VarHandleSegmentViewBase: https://github.com/openjdk/panama-foreign/blob/cbaf7084417a2f87ddf7a8721893931d02416271/src/java.base/share/classes/java/lang/invoke/VarHandleSegmentViewBase.java#L61

I think it might be better to fix this in the panama-foreign repo, and then move over to this repo after the JEP for 22 is integrated (which contains some of the new code).

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

PR Comment: https://git.openjdk.org/jdk/pull/15742#issuecomment-1721227791

From asemenyuk at openjdk.org  Fri Sep 15 13:32:39 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Sep 2023 13:32:39 GMT
Subject: RFR: 8301247: JPackage app-image exe launches multiple exe's in
 JDK 17+ [v2]
In-Reply-To: 
References: 
Message-ID: 

> On Windows, restart app launcher in a way that when the parent app launcher process terminates, the child app launcher process is automatically terminated.

Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:

 - Misplaced canRunLauncher() check.
 - Added a test to cover the test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15690/files
  - new: https://git.openjdk.org/jdk/pull/15690/files/ef5bf406..f09d39d4

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

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

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

From asemenyuk at openjdk.org  Fri Sep 15 13:32:40 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Sep 2023 13:32:40 GMT
Subject: RFR: 8301247: JPackage app-image exe launches multiple exe's in
 JDK 17+
In-Reply-To: 
References: 
Message-ID: 

On Tue, 12 Sep 2023 19:47:19 GMT, Alexey Semenyuk  wrote:

> On Windows, restart app launcher in a way that when the parent app launcher process terminates, the child app launcher process is automatically terminated.

Will add a test

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

PR Comment: https://git.openjdk.org/jdk/pull/15690#issuecomment-1716454873

From pminborg at openjdk.org  Fri Sep 15 13:54:52 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 15 Sep 2023 13:54:52 GMT
Subject: RFR: 8316196: VarHandleSegmentViewBase::newIllegalArg... to use
 hexadecimal form [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 06:06:18 GMT, Per Minborg  wrote:

>> This PR proposes to use hexadecimal formatting for raw addresses in `VarHandleSegmentViewBase`.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into vh-hex
>  - VarHandleSegmentViewBase::newIllegalArg... to use hexadecimal form

This PR will be closed in favor of a new one targeted at the Panama repo.

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

PR Comment: https://git.openjdk.org/jdk/pull/15742#issuecomment-1721319637

From pminborg at openjdk.org  Fri Sep 15 13:54:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 15 Sep 2023 13:54:54 GMT
Subject: Withdrawn: 8316196: VarHandleSegmentViewBase::newIllegalArg... to use
 hexadecimal form
In-Reply-To: 
References: 
Message-ID: 

On Thu, 14 Sep 2023 13:45:30 GMT, Per Minborg  wrote:

> This PR proposes to use hexadecimal formatting for raw addresses in `VarHandleSegmentViewBase`.

This pull request has been closed without being integrated.

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

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

From hannesw at openjdk.org  Fri Sep 15 14:05:07 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 15 Sep 2023 14:05:07 GMT
Subject: RFR: JDK-8315921: Invalid CSS declarations in java.lang class
 documentation
Message-ID: 

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.

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

Commit messages:
 - JDK-8315921: Invalid CSS declarations in java.lang class documentation

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

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

From ethan at mccue.dev  Fri Sep 15 14:31:17 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 15 Sep 2023 10:31:17 -0400
Subject: Should we actually make Connection a TemplateProcessor?
Message-ID: 

One of the examples in the String Template JEPs, and a stated motivating
factor behind its design, is SQL. Template processors are objects so that
use cases like constructing SQL statements aren't injection prone.

The questions I want to pose are:

* Should java.sql provide an implementation of TemplateProcessor
* Where should that implementation live?
* What, exactly, should be the translation strategy.

The reason I think this isn't an obvious yes and ask that last question is
this.

Say this is some user's code.

try (var conn = ds.getConnection();
     var stmt = conn.prepareStatement("""
         SELECT user.name
         WHERE user.height > ? AND user.width < ?
         """)) {
    stmt.setInt(1, height);
    stmt.setInt(2, width);
    var rs = stmt.executeQuery();
    process(rs);
}

The transliteration to string templates would be something like

try (var conn = ds.getConnection();
     var stmt = conn."""
         SELECT user.name
         WHERE user.height > \{height} AND user.width < \{width}
         """)) {
    var rs = stmt.executeQuery();
    process(rs);
}

Whether Connection implements TemplateProcessor directly or its something
that you wrap a connection with is somewhat immaterial.

How should we handle "partial templating"?

try (var conn = ds.getConnection();
     var stmt = conn."""
         SELECT user.name
         WHERE user.height > ? AND user.width < \{width}
         """)) {
    var rs = stmt.executeQuery();
    rs.setInt(1, height);
    process(rs);
}

Or

try (var conn = ds.getConnection();
     var stmt = conn."""
         SELECT user.name
         WHERE user.height > \{height} AND user.width < ?
         """)) {
    var rs = stmt.executeQuery();
    rs.setInt(2, width);
    process(rs);
}

Is replacing every substitution with ? and calling set* is enough? How
could it be known, without parsing the specific sql dialect, what index to
use for the parameter?

try (var conn = ds.getConnection();
     var stmt = conn."""
         SELECT user.name
         WHERE user.name <> '???'
             AND user.height > ?
             AND user.width < \{width}
         """)) {
    var rs = stmt.executeQuery();
    rs.setInt(1, height);
    process(rs);
}

(this seems more library design than language design, hence I sent it here.
I can forward to amber-dev if that is better)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alanb at openjdk.org  Fri Sep 15 14:38:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Sep 2023 14:38:41 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist
In-Reply-To: 
References: 
 
 <5nGQ3XRmhjhiYRl4Y4IvGQ1Qu24kQmfMoLdNNdOiWPc=.dc573a6c-e552-426d-bb94-e1f2a97e2a9d@github.com>
 
Message-ID: 

On Thu, 14 Sep 2023 18:03:48 GMT, Brian Burkhalter  wrote:

> If this code does not interact with ACL-based security, then it's not clear to me that there's anything to be done here.

Right, these methods were created with POSIX file permissions in mind. On the surface, the only result it can return is false (to mean fail) but the concern is that it would be an incompatible change so we need to think a bit more about it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15673#discussion_r1327379363

From shade at openjdk.org  Fri Sep 15 14:40:43 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Sep 2023 14:40:43 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Aug 2023 20:00:49 GMT, Nikita Sakharin  wrote:

>> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
>> 
>> final int size = (1 << 30) + 1;
>> final List list = new ArrayList<>(size);
>> for (int i = 0; i < size; ++i)
>>     list.add((byte) 0);
>> Collections.rotate(list, size - 1);
>> 
>> Output:
>> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
>> 
>> In that case private method `Collections.rotate1` will be called. And the line:
>> `i += distance;`
>> will cause overflow. I fixed this method and wrote a test for it.
>> 
>> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
>> 
>> Kindly ask you to raise a bug.
>
> Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314236: add comment for test

I would like to push this early next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/15270#issuecomment-1721389082

From vromero at openjdk.org  Fri Sep 15 14:45:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Sep 2023 14:45:49 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 09:42:24 GMT, Adam Sotona  wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed TestClassNameWarning test

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11411#pullrequestreview-1629114888

From duke at openjdk.org  Fri Sep 15 14:58:50 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Fri, 15 Sep 2023 14:58:50 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...

Hi @stuart-marks,

Say we allow large-array BitSets, then this would be my suggestion for methods that are still allowed for such large bitsets:
And(), AndNot(), Or(), Xor(), clone(), hashCode(), toLongArray(), and toByteArray()*. 
*: toByteArray() throws an exception if we create a bitset that is too big to fit in a byteArray, eg:

static final int MAX_WIU = Integer.MAX_VALUE/64 + 1;
long[] arr = new long[8*MAX_WIU + 1];
arr [ arr.length - 1] = 1;
BitSet broken = BitSet.valueOf(arr);
byte[] byteAr = broken.toByteArray(); // java.lang.NegativeArraySizeException: -2147483647

We could then state in the specifications of the valueOf(.. X ) methods (and clone(..)) that objects X of a certain size can only use the methods listed above. 

That being said, this concept is still risky. Say we pass a (large) bitset object to a client class / other methods with a bitset parameter, then these other classes/methods can suddenly no longer rely on this being a safe bitset object fullfilling the spec (class inv + all the method contracts). Alternatively, we could add to the specification of all other methods, how they should behave for such large bitsets. Such changes to the basic operations of the class are unlikely to be backwards compatible. Allowing large objects from valueOf(..) could just as easily break existing implementations, as these client classes would previously assume they can only deal with 'normal' bitsets, and would probably not have been made for the large-object spec.
It seems to me that this is at least as bad as banning large arrays in valueOf(..): the whole point of objects and methods with (Javadoc) specs is that you can trust that objects will always hold to these specs.

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

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1721416793

From james.laskey at oracle.com  Fri Sep 15 15:00:11 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 15 Sep 2023 15:00:11 +0000
Subject: Should we actually make Connection a TemplateProcessor?
In-Reply-To: 
References: 
Message-ID: 

I?ve been tinkering with just such an implementation. Here are a few issues that I?m sussing out:

- compound templates (partial templates)
- identifier vs string
- lists of identifiers, strings and values
      - list separators (comma, or, and)
- lack of meta data for some platforms
- odd ball data types (blobs)

There are others but these are the ones I?m starting with. There are lots of options to play with; format specification, DSL, new data types.

I?ll be looking for input from the experts leading to a JEP at some point, but haven?t worked out the forum as yet. Stay tuned.

Cheers,

? Jim




?

On Sep 15, 2023, at 11:31 AM, Ethan McCue  wrote:

strategy.

The reason I think this isn't an obvious yes and ask that last question is this.

Say this is some user's code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From asemenyuk at openjdk.org  Fri Sep 15 15:47:54 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Sep 2023 15:47:54 GMT
Subject: RFR: 8314909: tools/jpackage/windows/Win8282351Test.java fails with
 java.lang.AssertionError: Expected [0]. Actual [1618]:
Message-ID: 

Run jpackage jtreg tests on Windows sequentially. Asynch execution of `msiexec.exe` that unpacks msi files doesn't work well.

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

Commit messages:
 - 8314909: tools/jpackage/windows/Win8282351Test.java fails with java.lang.AssertionError: Expected [0]. Actual [1618]:

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

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

From naoto at openjdk.org  Fri Sep 15 16:22:39 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Sep 2023 16:22:39 GMT
Subject: RFR: 8316187: Modernize an example in StringTokenizer
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 12:39:00 GMT, Pavel Rappo  wrote:

> This modernizes an example to use the extended for-statement introduced in JDK 1.5.
> 
> I understand that StringTokenizer is a legacy class. But legacy or not, a class shouldn't promote older constructs when newer fit better. Especially when advising on preferred alternatives to itself.
> 
> That said, I wouldn't go as far as to use `var` anywhere in that example: JDK 10, which introduced `var`, might still be relatively new to some. Nor would I inline the call to `String.split` in the for-statement to dispense with the `String[] result` variable: I reckon it's good for a reader unfamiliar with `String.split` to see the type it returns.
> 
> Perhaps one additional thing to ponder is this: we could either add `@see` to point to `String.split` or make the whole example a `@snippet`, which `@link`s code to the definition of `String.split`.

No need to create another PR for such changes IMO.
Although it may be a bit odd to re-use the same variable names for different types, I might keep the original `myDate`/`myNumber` that aligns with other locations in the class descriptions.

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

PR Comment: https://git.openjdk.org/jdk/pull/15716#issuecomment-1721538491

From asotona at openjdk.org  Fri Sep 15 16:28:44 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Sep 2023 16:28:44 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v16]
In-Reply-To: 
References: 
Message-ID: 

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

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

  adding serviceability/sa/ClhsdbDumpclass.java test to problem list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/ae3b25bf..3ae33d48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=14-15

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

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

From naoto at openjdk.org  Fri Sep 15 16:56:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Sep 2023 16:56:48 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Consonant Break specified in the latest Unicode Annex #29 ("Unicode Text Segmentation") is included. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
   
   Co-authored-by: Andrey Turbanov 
 - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
   
   Co-authored-by: Andrey Turbanov 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15728/files
  - new: https://git.openjdk.org/jdk/pull/15728/files/1ba53e8b..10527c07

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

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

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

From prappo at openjdk.org  Fri Sep 15 17:35:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 15 Sep 2023 17:35:51 GMT
Subject: Integrated: 8316207: Fix typos in java.io.StreamTokenizer
In-Reply-To: <6x1Hpv-9vQ5hyP6KSDcFEshLeWKpT0BaVyw_HnlusYk=.28bb20b8-2c84-4218-b2f3-2a31196a31cb@github.com>
References: <6x1Hpv-9vQ5hyP6KSDcFEshLeWKpT0BaVyw_HnlusYk=.28bb20b8-2c84-4218-b2f3-2a31196a31cb@github.com>
Message-ID: 

On Wed, 13 Sep 2023 15:43:45 GMT, Pavel Rappo  wrote:

> This is a simple PR to fix a few typos in the doc comments of java.io.StreamTokenizer. When reviewing it, please double-check my proposal for L481. For this, you should ideally read the complete comment to the `lowerCaseMode` method. Thanks!

This pull request has now been integrated.

Changeset: 149acd18
Author:    Pavel Rappo 
URL:       https://git.openjdk.org/jdk/commit/149acd186ed68d290e22dc2c86e17f46ef68b124
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8316207: Fix typos in java.io.StreamTokenizer

Reviewed-by: naoto

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

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

From prappo at openjdk.org  Fri Sep 15 18:06:10 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 15 Sep 2023 18:06:10 GMT
Subject: RFR: 8316187: Modernize an example in StringTokenizer [v2]
In-Reply-To: 
References: 
Message-ID: 

> This modernizes an example to use the extended for-statement introduced in JDK 1.5.
> 
> I understand that StringTokenizer is a legacy class. But legacy or not, a class shouldn't promote older constructs when newer fit better. Especially when advising on preferred alternatives to itself.
> 
> That said, I wouldn't go as far as to use `var` anywhere in that example: JDK 10, which introduced `var`, might still be relatively new to some. Nor would I inline the call to `String.split` in the for-statement to dispense with the `String[] result` variable: I reckon it's good for a reader unfamiliar with `String.split` to see the type it returns.
> 
> Perhaps one additional thing to ponder is this: we could either add `@see` to point to `String.split` or make the whole example a `@snippet`, which `@link`s code to the definition of `String.split`.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Tag on a few more cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15716/files
  - new: https://git.openjdk.org/jdk/pull/15716/files/1bb3370a..f452189b

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

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

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

From prappo at openjdk.org  Fri Sep 15 18:06:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 15 Sep 2023 18:06:11 GMT
Subject: RFR: 8316187: Modernize an example in StringTokenizer
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 16:20:15 GMT, Naoto Sato  wrote:

> No need to create another PR for such changes IMO.
> Although it may be a bit odd to re-use the same variable names for different types, I might keep the original `myDate`/`myNumber` that aligns with other locations in the class descriptions.

Applied your suggestion and added as a new commit: f452189bfb6. Please double-check if that's what you meant.

Let me clarify the change to NumberFormat. Earlier in this PR, I said that `var` might still be relatively new to some. While true, in this case it's either `var` or the existing code, which applies to arrays, but not to `Iterable`s.

The reason is that unlike DateFormat, NumberFormat has two relevant overloads of `format`: one for `long` and another one for `double`. To keep the example type-agnostic, we should avoid explicit type in call to `format`. To that end, either `var` or avoiding the variable altogether would equally do.

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

PR Comment: https://git.openjdk.org/jdk/pull/15716#issuecomment-1721650174

From naoto at openjdk.org  Fri Sep 15 18:14:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Sep 2023 18:14:40 GMT
Subject: RFR: 8316187: Modernize an example in StringTokenizer [v2]
In-Reply-To: 
References: 
 
Message-ID: <0ZpVEhBa1lhUxLezLQvPzFOG1VqumiyZPNb8HV8N2Js=.f932ce37-39e6-403e-9715-9471e1ee5bb7@github.com>

On Fri, 15 Sep 2023 18:06:10 GMT, Pavel Rappo  wrote:

>> This modernizes an example to use the extended for-statement introduced in JDK 1.5.
>> 
>> I understand that StringTokenizer is a legacy class. But legacy or not, a class shouldn't promote older constructs when newer fit better. Especially when advising on preferred alternatives to itself.
>> 
>> That said, I wouldn't go as far as to use `var` anywhere in that example: JDK 10, which introduced `var`, might still be relatively new to some. Nor would I inline the call to `String.split` in the for-statement to dispense with the `String[] result` variable: I reckon it's good for a reader unfamiliar with `String.split` to see the type it returns.
>> 
>> Perhaps one additional thing to ponder is this: we could either add `@see` to point to `String.split` or make the whole example a `@snippet`, which `@link`s code to the definition of `String.split`.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tag on a few more cases

Still LGTM. Good point to use `var` for making it type agnostic.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15716#pullrequestreview-1629492143

From jlu at openjdk.org  Fri Sep 15 18:54:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 15 Sep 2023 18:54:19 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
> 
> `forceStandardTime` is always false.
> 
> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
> 
> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.

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

  Clarify implementation after removal of if else block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15726/files
  - new: https://git.openjdk.org/jdk/pull/15726/files/5a3375ec..2a2b0e7f

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

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

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

From jlu at openjdk.org  Fri Sep 15 19:07:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 15 Sep 2023 19:07:41 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v4]
In-Reply-To: 
References: 
 
Message-ID: <71Nka7KC7k1oXQ1vbC2hVJ6_4sRaabUtJFg-uahlodA=.015e0f6b-28aa-4aa4-9e54-8694e1cab81e@github.com>

On Fri, 15 Sep 2023 18:54:19 GMT, Justin Lu  wrote:

>> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
>> 
>> `forceStandardTime` is always false.
>> 
>> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
>> 
>> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify implementation after removal of if else block

src/java.base/share/classes/sun/util/calendar/AbstractCalendar.java line 176:

> 174:             //    as 1:30am DT/0:30am ST (before transition)
> 175:             if (zi instanceof ZoneInfo zInfo) {
> 176:                 // Offset value adjusts accordingly depending on DST status of date

Historically, this `if else` has not been touched since the introduction of the class.

The original code has a structure that one can presume follows the logic, if `isStandardTime()`, get a standard offset, otherwise get a day light saving offset. This is not the case. 

The code within the `else` statement is able to retrieve the correct offset if the date is in standard **or** in day light saving time (not just a day light saving offset, as the original code would imply). Consider the following example,


// Where ms is calculated from the date: LA time zone at 3-13-2016 at 4 AM (daylight saving)
zoneOffset = zInfo.getOffsetsByWall(ms, new int[2]); 
// returns the adjusted offset, -25200000 (7 hours)

// Where ms is calculated from the date: LA time zone at 1-13-2016 at 4 AM (standard)
zoneOffset = zInfo.getOffsetsByWall(ms, new int[2]); 
// returns the standard offset, -28800000 (8 hours)

Removing this code is not only safe because `isStandardTime()` is always `false`
- tiers 1-3 clean
- breakpoint within the original `if` never breaks execution for JDK Calendar tests

But we can also feel that the change is not suspicious since the code within the `else` block can produce a standard or daylight offset.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1327678366

From bpb at openjdk.org  Fri Sep 15 19:13:31 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 19:13:31 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v2]
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: 

> Add a `finally` block to delete the created files.

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

  8315960: Convert test to JUnit 5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15757/files
  - new: https://git.openjdk.org/jdk/pull/15757/files/cc4d9f3f..dad75c58

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

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

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

From bpb at openjdk.org  Fri Sep 15 19:17:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 19:17:40 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v2]
In-Reply-To: <5uKa3kyld4gEQQNby5yqZNf_no53Gco9dG4sJclVQ-Q=.e8700cb9-d4a3-426f-a19b-c3d01d6b5e8e@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
 <5uKa3kyld4gEQQNby5yqZNf_no53Gco9dG4sJclVQ-Q=.e8700cb9-d4a3-426f-a19b-c3d01d6b5e8e@github.com>
Message-ID: 

On Thu, 14 Sep 2023 23:58:33 GMT, Brian Burkhalter  wrote:

> [...] perhaps it would be worthwhile to convert to Junit

Please see dad75c580e65c4cc76f8f59e25295d904eb61410.

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

PR Comment: https://git.openjdk.org/jdk/pull/15757#issuecomment-1721729369

From bpb at openjdk.org  Fri Sep 15 19:47:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 19:47:09 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v3]
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: 

> Add a `finally` block to delete the created files.

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

  8315960: Remove @BeforeAll method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15757/files
  - new: https://git.openjdk.org/jdk/pull/15757/files/dad75c58..2d444213

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

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

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

From naoto at openjdk.org  Fri Sep 15 20:15:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Sep 2023 20:15:41 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 18:54:19 GMT, Justin Lu  wrote:

>> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
>> 
>> `forceStandardTime` is always false.
>> 
>> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
>> 
>> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify implementation after removal of if else block

Marked as reviewed by naoto (Reviewer).

src/java.base/share/classes/sun/util/calendar/AbstractCalendar.java line 171:

> 169:             // adjust time zone and daylight saving
> 170:             // 1) 2:30am during starting-DST transition is
> 171:             //    intrepreted as 3:30am DT

Not your change, but I think this is a typo of `interpreted`

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

PR Review: https://git.openjdk.org/jdk/pull/15726#pullrequestreview-1629657227
PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1327739161

From naoto at openjdk.org  Fri Sep 15 20:15:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Sep 2023 20:15:44 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v4]
In-Reply-To: <71Nka7KC7k1oXQ1vbC2hVJ6_4sRaabUtJFg-uahlodA=.015e0f6b-28aa-4aa4-9e54-8694e1cab81e@github.com>
References: 
 
 <71Nka7KC7k1oXQ1vbC2hVJ6_4sRaabUtJFg-uahlodA=.015e0f6b-28aa-4aa4-9e54-8694e1cab81e@github.com>
Message-ID: 

On Fri, 15 Sep 2023 19:05:12 GMT, Justin Lu  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify implementation after removal of if else block
>
> src/java.base/share/classes/sun/util/calendar/AbstractCalendar.java line 176:
> 
>> 174:             //    as 1:30am DT/0:30am ST (before transition)
>> 175:             if (zi instanceof ZoneInfo zInfo) {
>> 176:                 // Offset value adjusts accordingly depending on DST status of date
> 
> Historically, this `if else` has not been touched since the introduction of the class.
> 
> The original code has a structure that one can presume follows the logic, if `isStandardTime()`, get a standard offset, otherwise get a day light saving offset. This is not the case. 
> 
> The code within the `else` statement is able to retrieve the correct offset if the date is in standard **or** in day light saving time (not just a day light saving offset, as the original code would imply). Consider the following example,
> 
> 
> // Where ms is calculated from the date: LA time zone at 3-13-2016 at 4 AM (daylight saving)
> zoneOffset = zInfo.getOffsetsByWall(ms, new int[2]); 
> // returns the adjusted offset, -25200000 (7 hours)
> 
> // Where ms is calculated from the date: LA time zone at 1-13-2016 at 4 AM (standard)
> zoneOffset = zInfo.getOffsetsByWall(ms, new int[2]); 
> // returns the standard offset, -28800000 (8 hours)
> 
> Removing this code is not only safe because `isStandardTime()` is always `false`
> - tiers 1-3 clean
> - breakpoint within the original `if` never breaks execution for JDK Calendar tests
> 
> But we can also feel that the change is not suspicious since the code within the `else` block can produce a standard or daylight offset.

I suspect that the original design is to have this overridden by possible subclasses if needed, but none has done so far (and I don't think it ever will). So I think it is safe (and less complex) to remove these unused codes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1327738047

From psandoz at openjdk.org  Fri Sep 15 20:19:41 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 15 Sep 2023 20:19:41 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>
 
Message-ID: <4gJ8559jIkiqFQNZHixQ1omfMjW7kKRtjaYFc92Xb90=.b64864d7-a56e-40bd-9581-d5abf97cb7e5@github.com>

On Fri, 1 Sep 2023 06:12:57 GMT, Alan Bateman  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.

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1721811993

From jlu at openjdk.org  Fri Sep 15 20:24:35 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 15 Sep 2023 20:24:35 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
> 
> `forceStandardTime` is always false.
> 
> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
> 
> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.

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

  cleanup existing typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15726/files
  - new: https://git.openjdk.org/jdk/pull/15726/files/2a2b0e7f..63ac1e9f

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

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

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

From almatvee at openjdk.org  Fri Sep 15 21:24:40 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 15 Sep 2023 21:24:40 GMT
Subject: RFR: 8314909: tools/jpackage/windows/Win8282351Test.java fails
 with java.lang.AssertionError: Expected [0]. Actual [1618]:
In-Reply-To: 
References: 
Message-ID: 

On Fri, 15 Sep 2023 15:40:25 GMT, Alexey Semenyuk  wrote:

> Run jpackage jtreg tests on Windows sequentially. Asynch execution of `msiexec.exe` that unpacks msi files doesn't work well.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15766#pullrequestreview-1629741284

From david.holmes at oracle.com  Fri Sep 15 21:50:51 2023
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 16 Sep 2023 07:50:51 +1000
Subject: Java 21 clinit deadlock
In-Reply-To: 
References: 
 <77f901c7-5bb8-4703-8c64-b331913516b6@oracle.com>
 
 
 
 
 <9eb34d59-f00d-4a73-9eaf-5353b4ba5838@oracle.com>
 
Message-ID: 

On 15/09/2023 5:00 pm, Simone Bordet wrote:
> David,
> 
> On Thu, Sep 14, 2023 at 4:33?AM David Holmes  wrote:
>> I've created a draft PR here:
>>
>> https://github.com/openjdk/jdk/pull/15732
>>
>> can you apply that patch, build and re-test? Hopefully that will show
>> which thread is doing the missing initialization.
> 
> We have attached the logs to the pull request above.
> 
> Seems like a classic deadlock:

Indeed it does. The reason this was not visible in the thread dump is 
that we have not reached the point of  execution for 
MutableHttpFields, but are blocked trying to get the class 
initialization lock for a superclass/interface to ensure it is 
initialized first.
> '[8.061s][debug][class,init] Thread ForkJoinPool-1-worker-1 is
> initializing org.eclipse.jetty.http.HttpFields'.
> ...
> '[8.113s][debug][class,init] Thread ForkJoinPool-1-worker-2 is
> initializing org.eclipse.jetty.http.MutableHttpFields'.
> '[8.113s][debug][class,init] Thread ForkJoinPool-1-worker-2 waiting
> for initialization of org.eclipse.jetty.http.HttpFields by thread
> ForkJoinPool-1-worker-1'.
> ...
> '[8.117s][debug][class,init] Thread ForkJoinPool-1-worker-1
> recursively initializing org.eclipse.jetty.http.HttpFields'.
> '[8.117s][debug][class,init] Thread ForkJoinPool-1-worker-1 waiting
> for initialization of org.eclipse.jetty.http.MutableHttpFields by
> thread ForkJoinPool-1-worker-2'.
> 
> It is peculiar that we already get this deadlock for the same classes.
> Perhaps we are using a pattern in the code that makes it more likely to happen?

Perhaps. I don't know the jetty code at all so you would need to go back 
to them with these findings. If two classes have a dependency on each 
other this way then you would normally expect there to be a preferred 
"entry point" so that initialization will always occur in the same 
order. But it is a fragile design where a superclass/interface uses its 
own subclass in its static initialization.

Glad this helped expose the problem.

Cheers,
David
-----

> Thanks!
> 

From bpb at openjdk.org  Fri Sep 15 21:51:22 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 21:51:22 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v4]
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: 

> Add a `finally` block to delete the created files.

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

  8315960: Remove vestigial unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15757/files
  - new: https://git.openjdk.org/jdk/pull/15757/files/2d444213..f940caed

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

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

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

From duke at openjdk.org  Fri Sep 15 22:17:42 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 15 Sep 2023 22:17:42 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v37]
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 incrementally with one additional commit since the last revision:

  Move functional interfaces close to the associated methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/172b2d3e..e63a2aa0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=35-36

  Stats: 77 lines in 2 files changed: 35 ins; 35 del; 7 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  Fri Sep 15 22:17:43 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 15 Sep 2023 22:17:43 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v36]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 13 Sep 2023 23:00:23 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:
> 
>   Refactor the sort and partition intrinsics to accept method references for fallback functions

Hello Paul,

As suggested, the functional interfaces were moved next to the associated methods and also added a `@ForceInline` for `arraySort` in the latest commit.

> I recommend embedding the functional interfaces next to the associated methods, rather than as auxiliary classes, and also adding `@ForceInline` on `arraySort`.

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1721927385

From naoto at openjdk.org  Fri Sep 15 23:35:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Sep 2023 23:35:42 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 20:24:35 GMT, Justin Lu  wrote:

>> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
>> 
>> `forceStandardTime` is always false.
>> 
>> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
>> 
>> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup existing typos

I have to retract the PR approval for the said reason

src/java.base/share/classes/sun/util/calendar/ImmutableGregorianDate.java line 160:

> 158:         unsupported();
> 159:     }
> 160: 

This removal does not look right. The class claims `immutable`, and yet it is now allowing setting the locale.

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

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15726#pullrequestreview-1629850335
PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1327862262

From almatvee at openjdk.org  Fri Sep 15 23:45:37 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 15 Sep 2023 23:45:37 GMT
Subject: RFR: 8301247: JPackage app-image exe launches multiple exe's in
 JDK 17+ [v2]
In-Reply-To: 
References: 
 
Message-ID: <9_lDqlFMeR2Jw9k9aSBjFOeb4oEHuUvoarqRKsuGCJ8=.9d858289-062a-44b8-a3f6-4880ee4efa9c@github.com>

On Fri, 15 Sep 2023 13:32:39 GMT, Alexey Semenyuk  wrote:

>> On Windows, restart app launcher in a way that when the parent app launcher process terminates, the child app launcher process is automatically terminated.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Misplaced canRunLauncher() check.
>  - Added a test to cover the test case

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15690#pullrequestreview-1629860059

From jbhateja at openjdk.org  Sat Sep 16 03:04:53 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 16 Sep 2023 03:04:53 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v37]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 22:17:42 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:
> 
>   Move functional interfaces close to the associated methods

Marked as reviewed by jbhateja (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14227#pullrequestreview-1629892083

From duke at openjdk.org  Sat Sep 16 06:20:49 2023
From: duke at openjdk.org (chenggwang)
Date: Sat, 16 Sep 2023 06:20:49 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: 
References: 
 
Message-ID: <0OohWyhflC-EaNfoLJpr8QIR4asCuPzp8k_I6mezuKQ=.63f070fb-788a-44dc-bb1c-9a83db394cef@github.com>

On Tue, 12 Sep 2023 16:11:56 GMT, Martin Buchholz  wrote:

> We should try to retain designed immutability in concurrency classes. Having had the experience of having fixed many bugs with knobs tunable at runtime. If you make a field mutable, you need to think not just about "set", but also about "compare and set", "freeze" and security implications of adding a new form of attack.
> 
> So let's leave CyclicBarrier unchanged.

Thank you very much, it's an honor to be guided by you, I did overlook the potential safety risks posed by mutable

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

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1722149752

From duke at openjdk.org  Sat Sep 16 06:20:50 2023
From: duke at openjdk.org (chenggwang)
Date: Sat, 16 Sep 2023 06:20:50 GMT
Subject: Withdrawn: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang  wrote:

> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous and makes you think of Phaser. My intention is that each generation of CyclicBarrier barrierCommand can change. Let me give you a scenario
> For example, the U.S. Army 'Gordon Sullivan Cup'.
> Five tanks competing.
> 1. The first round is for artillery strikes against targets.
> 2. Second round of anti-aircraft machine gun targets.
> 3. The third round is minefield racing.
> The scoring criteria are different for each round, so the CyclicBarrier's barrierCommand should be different for each round. But in the current code, `private final Runnable barrierCommand`, constructing the CyclicBarrier instance is already determined to be unchangeable.

This pull request has been closed without being integrated.

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

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

From aturbanov at openjdk.org  Sat Sep 16 07:40:41 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 16 Sep 2023 07:40:41 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 15 Sep 2023 23:31:16 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup existing typos
>
> src/java.base/share/classes/sun/util/calendar/ImmutableGregorianDate.java line 160:
> 
>> 158:         unsupported();
>> 159:     }
>> 160: 
> 
> This removal does not look right. The class claims `immutable`, and yet it is now allowing setting the locale.

There is no `setLocale` method in the base class anymore. So, it's not possible to set locale in any classes which extend `BaseCalendar.Date`, including `ImmutableGregorianDate`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1327921070

From prappo at openjdk.org  Sat Sep 16 07:54:56 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Sat, 16 Sep 2023 07:54:56 GMT
Subject: Integrated: 8316187: Modernize examples in StringTokenizer and
 {Date,Number}Format
In-Reply-To: 
References: 
Message-ID: <2clhXe3ughmFH2Bw5Uf2MFUnKRm9dqz37qJu6qckm7A=.8eb6ce9a-8981-4c5e-8dcb-8245af5dea32@github.com>

On Wed, 13 Sep 2023 12:39:00 GMT, Pavel Rappo  wrote:

> This modernizes an example to use the extended for-statement introduced in JDK 1.5.
> 
> I understand that StringTokenizer is a legacy class. But legacy or not, a class shouldn't promote older constructs when newer fit better. Especially when advising on preferred alternatives to itself.
> 
> That said, I wouldn't go as far as to use `var` anywhere in that example: JDK 10, which introduced `var`, might still be relatively new to some. Nor would I inline the call to `String.split` in the for-statement to dispense with the `String[] result` variable: I reckon it's good for a reader unfamiliar with `String.split` to see the type it returns.
> 
> Perhaps one additional thing to ponder is this: we could either add `@see` to point to `String.split` or make the whole example a `@snippet`, which `@link`s code to the definition of `String.split`.

This pull request has now been integrated.

Changeset: c92bdb0e
Author:    Pavel Rappo 
URL:       https://git.openjdk.org/jdk/commit/c92bdb0e917e1251c0c2ef6b873df702b816c1f4
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

8316187: Modernize examples in StringTokenizer and {Date,Number}Format

Reviewed-by: naoto

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

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

From dl at openjdk.org  Sat Sep 16 12:41:38 2023
From: dl at openjdk.org (Doug Lea)
Date: Sat, 16 Sep 2023 12:41:38 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v34]
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 81 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Fix header; don't shadow park state
 - Merge branch 'openjdk:master' into JDK-8288899
 - Revert Unsafe; reduce signal stalls
 - Merge branch 'openjdk:master' into JDK-8288899
 - Strengthen translation of getAndX atomics; revert or adapt FJP accordingly
 - Merge branch 'openjdk:master' into JDK-8288899
 - Force more orderings; improve diagnostics
 - Simplify signalling
 - Always help terminate when stopping
 - ... and 71 more: https://git.openjdk.org/jdk/compare/aa2d2b07...e0ec06db

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/b9792f67..e0ec06db

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

  Stats: 457 lines in 16 files changed: 316 ins; 104 del; 37 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  Sat Sep 16 13:38:29 2023
From: dl at openjdk.org (Doug Lea)
Date: Sat, 16 Sep 2023 13:38:29 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v35]
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:

  Accommodate parallelism 0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/e0ec06db..907ad02b

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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 Sep 16 21:30:39 2023
From: duke at openjdk.org (iaroslavski)
Date: Sat, 16 Sep 2023 21:30:39 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v9]
In-Reply-To: <4gJ8559jIkiqFQNZHixQ1omfMjW7kKRtjaYFc92Xb90=.b64864d7-a56e-40bd-9581-d5abf97cb7e5@github.com>
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 Fri, 15 Sep 2023 20:17:17 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 @PaulSandoz Paul, @AlanBateman Alan,

I agree that additional memory must not change current behavior of the core.

When parallel sort was introduced in JDK 8, parallel implementation with additional
memory in merge sort went to the new method Arrays.parallelSort  instead of Arrays.sort
to be sure that existing applications will not broken.

We take care of memory usages in sequential sorting, therefore I suggest the
following variant: what if we introduce Radix sort for parallel sorting only?

There are no memory changes in sequential sorting and in parallel sorting Radix
sort will reuse buffer from parallel merge sort. It means there is no potential
increased use of memory at all, no risk, we will keep current behavior. It is easy
to adapt new implementation: one changed line for each type int/long/float/double.

Paul, Alan,
Do you agree with such idea?

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1722319763

From duke at openjdk.org  Sat Sep 16 22:51:56 2023
From: duke at openjdk.org (iaroslavski)
Date: Sat, 16 Sep 2023 22:51:56 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v36]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 15 Sep 2023 22:11:44 GMT, Srinivas Vamsi Parasa  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor the sort and partition intrinsics to accept method references for fallback functions
>
> Hello Paul,
> 
> As suggested, the functional interfaces were moved next to the associated methods and also added a `@ForceInline` for `arraySort` in the latest commit.
> 
>> I recommend embedding the functional interfaces next to the associated methods, rather than as auxiliary classes, and also adding `@ForceInline` on `arraySort`.
> 
> Thanks,
> Vamsi

Hi @vamsi-parasa 

Why do we need ``if (indexPivot1 != indexPivot2) throw new IllegalArgumentException()``?
If you implement logic correctly, you will never throw the exception.
It is not business case, when exception makes sence.
Therefore, I suggest removing this check.

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1722333799

From naoto at openjdk.org  Sat Sep 16 23:30:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 16 Sep 2023 23:30:43 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sat, 16 Sep 2023 07:37:37 GMT, Andrey Turbanov  wrote:

>> src/java.base/share/classes/sun/util/calendar/ImmutableGregorianDate.java line 160:
>> 
>>> 158:         unsupported();
>>> 159:     }
>>> 160: 
>> 
>> This removal does not look right. The class claims `immutable`, and yet it is now allowing setting the locale.
>
> There is no `setLocale` method in the base class anymore. So, it's not possible to set locale in any classes which extend `BaseCalendar.Date`, including `ImmutableGregorianDate`

It is ok then. (missed the removal of the method in the abstract class). Now come to think of it, I would like them to be `sealed` to make sure they are not randomly subclassed, but that clean-up is for another day.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15726#discussion_r1328020279

From naoto at openjdk.org  Sat Sep 16 23:30:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 16 Sep 2023 23:30:41 GMT
Subject: RFR: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set [v5]
In-Reply-To: 
References: 
 
Message-ID: <3vGDr_JUdhnkm4klY3kiuUpOasCrN5iFEmLNweHnITc=.890d7d1f-319e-4850-91bf-112373be392a@github.com>

On Fri, 15 Sep 2023 20:24:35 GMT, Justin Lu  wrote:

>> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
>> 
>> `forceStandardTime` is always false.
>> 
>> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
>> 
>> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup existing typos

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15726#pullrequestreview-1630021636

From duke at openjdk.org  Sun Sep 17 07:08:00 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 17 Sep 2023 07:08:00 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v12]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 7 Sep 2023 19:27:14 GMT, Mandy Chung  wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information.  If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO`
>> can be used instead and such stack walker will save the overhead of extracting the method information
>> and the memory used for the stack walking.
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can create a stack walker instance with `DROP_METHOD_INFO` option:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(Predicate.not(implClasses::contains))
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> ` T walkClass(Function, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> ### Implementation Details
>> 
>> A `StackWalker` configured with `DROP_METHOD_INFO` ...
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix @Param due to the rename from default to class+method

src/java.base/share/classes/java/lang/ClassFrameInfo.java line 40:

> 38:  * @see StackWalker.Option#DROP_METHOD_INFO
> 39:  */
> 40: class ClassFrameInfo implements StackFrame {

This class can be `sealed`:
Suggestion:

sealed class ClassFrameInfo implements StackFrame permits StackFrameInfo {

src/java.base/share/classes/java/lang/StackFrameInfo.java line 93:

> 91:         synchronized (this) {
> 92:             if (type instanceof String sig) {
> 93:                 type = JLIA.getMethodType(sig, declaringClass().getClassLoader());

Maybe?there should?be a?`return`?here:
Suggestion:

                return type = JLIA.getMethodType(sig, declaringClass().getClassLoader());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1328054480
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1328053888

From liach at openjdk.org  Sun Sep 17 07:46:00 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 17 Sep 2023 07:46:00 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v12]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sun, 17 Sep 2023 06:57:46 GMT, ExE Boss  wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix @Param due to the rename from default to class+method
>
> src/java.base/share/classes/java/lang/StackFrameInfo.java line 93:
> 
>> 91:         synchronized (this) {
>> 92:             if (type instanceof String sig) {
>> 93:                 type = JLIA.getMethodType(sig, declaringClass().getClassLoader());
> 
> Maybe?there should?be a?`return`?here:
> Suggestion:
> 
>                 return type = JLIA.getMethodType(sig, declaringClass().getClassLoader());

`type` is of type `Object`, don't think this compiles as the result type of `=` is the `type` variable's type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1328057872

From lancea at openjdk.org  Sun Sep 17 11:17:30 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 17 Sep 2023 11:17:30 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v4]
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 five additional commits since the last revision:

 - 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/24b159d8..afc9d7d0

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

  Stats: 89465 lines in 2912 files changed: 37847 ins; 14022 del; 37596 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 lancea at openjdk.org  Sun Sep 17 13:35:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 17 Sep 2023 13:35:13 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v5]
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 six additional commits since the last revision:

 - 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/afc9d7d0..f64a70c3

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

  Stats: 56 lines in 3 files changed: 18 ins; 1 del; 37 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 mdonovan at openjdk.org  Sun Sep 17 23:49:38 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Sun, 17 Sep 2023 23:49:38 GMT
Subject: RFR: 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.

Hi, I'm still looking for a reviewer for this PR. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14932#issuecomment-1722601105

From dholmes at openjdk.org  Mon Sep 18 01:46:37 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Sep 2023 01:46:37 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v3]
In-Reply-To: 
References: 
 <2rTLX86raFjJBNOlUysJoxGB8UaGLH7szSa_EOmXEDE=.e545fc08-9354-4173-b88f-b8173c3878b7@github.com>
 
 
 
 
 
Message-ID: 

On Fri, 15 Sep 2023 06:34:52 GMT, Alan Bateman  wrote:

>> What is TIMED PINNING? 
>> 
>> To me TIMED_X are a specific set of states and there are not enough of them to consider TIMED to be a bit that can be applied to any state X.
>
>> What is TIMED PINNING?
> 
> LockSupport.parkNanos when the carrier can't be released due to monitor or native frame.

Surely that is not a specified exported thread state though ?? Why would we care about PINNED (timed or otherwise) in the current context?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1328191555

From duke at openjdk.org  Mon Sep 18 02:53:18 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 02:53:18 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v8]
In-Reply-To: 
References: 
Message-ID: 

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLo...

??? has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into optimization_for_string_latin1_upper_lower
 - Merge branch 'master' into optimization_for_string_latin1_upper_lower
 - Merge branch 'master' of github.com:wenshao/jdk into optimization_for_string_latin1_upper_lower
 - rename hasNotUpperCaseEx to hasUpperCaseMapping
 - rename isLowerCaseEx to hasNotUpperCaseEx
 - use hex literal
 - add method CharacterDataLatin1#isLowerCaseEx
 - remove unnecessary code
 - optimization for StringLatin1 UpperLower

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14751/files
  - new: https://git.openjdk.org/jdk/pull/14751/files/a38f8870..e982d350

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

  Stats: 69497 lines in 2323 files changed: 24238 ins; 10975 del; 34284 mod
  Patch: https://git.openjdk.org/jdk/pull/14751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14751/head:pull/14751

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

From liach at openjdk.org  Mon Sep 18 03:03:48 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Sep 2023 03:03:48 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 02:53:18 GMT, ???  wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into optimization_for_string_latin1_upper_lower
>  - Merge branch 'master' into optimization_for_string_latin1_upper_lower
>  - Merge branch 'master' of github.com:wenshao/jdk into optimization_for_string_latin1_upper_lower
>  - rename hasNotUpperCaseEx to hasUpperCaseMapping
>  - rename isLowerCaseEx to hasNotUpperCaseEx
>  - use hex literal
>  - add method CharacterDataLatin1#isLowerCaseEx
>  - remove unnecessary code
>  - optimization for StringLatin1 UpperLower

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 93:

> 91:     }
> 92: 
> 93:     boolean hasUpperCaseMapping(int ch) {

This method is incorrectly named; it actually tests that a char has no upper case mapping. I recommend fixing this by keeping the method name while removing the double `!` at this return and at the if down below to simplify the logic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1328210737

From duke at openjdk.org  Mon Sep 18 03:51:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 03:51:11 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v9]
In-Reply-To: 
References: 
Message-ID: 

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLo...

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

  refactor removing the double !

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14751/files
  - new: https://git.openjdk.org/jdk/pull/14751/files/e982d350..5f10bc27

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

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

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

From duke at openjdk.org  Mon Sep 18 04:11:25 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 04:11:25 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v10]
In-Reply-To: 
References: 
Message-ID: 

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLo...

??? has updated the pull request incrementally with two additional commits since the last revision:

 - refactor removing the double !
 - refactor removing the double !

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14751/files
  - new: https://git.openjdk.org/jdk/pull/14751/files/5f10bc27..3f370b19

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

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

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

From duke at openjdk.org  Mon Sep 18 04:11:31 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 04:11:31 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 18 Sep 2023 03:00:25 GMT, Chen Liang  wrote:

>> ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into optimization_for_string_latin1_upper_lower
>>  - Merge branch 'master' into optimization_for_string_latin1_upper_lower
>>  - Merge branch 'master' of github.com:wenshao/jdk into optimization_for_string_latin1_upper_lower
>>  - rename hasNotUpperCaseEx to hasUpperCaseMapping
>>  - rename isLowerCaseEx to hasNotUpperCaseEx
>>  - use hex literal
>>  - add method CharacterDataLatin1#isLowerCaseEx
>>  - remove unnecessary code
>>  - optimization for StringLatin1 UpperLower
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 93:
> 
>> 91:     }
>> 92: 
>> 93:     boolean hasUpperCaseMapping(int ch) {
> 
> This method is incorrectly named; it actually tests that a char has no upper case mapping. I recommend fixing this by keeping the method name while removing the double `!` at this return and at the if down below to simplify the logic.

Now use a local variable notUpperCaseEx, I prefer this, without adding a method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1328232378

From alanb at openjdk.org  Mon Sep 18 05:47:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Sep 2023 05:47:45 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v3]
In-Reply-To: 
References: 
 <2rTLX86raFjJBNOlUysJoxGB8UaGLH7szSa_EOmXEDE=.e545fc08-9354-4173-b88f-b8173c3878b7@github.com>
 
 
 
 
 
 
Message-ID: 

On Mon, 18 Sep 2023 01:44:10 GMT, David Holmes  wrote:

> Surely that is not a specified exported thread state though ?? Why would we care about PINNED (timed or otherwise) in the current context?

There are internal states and then mappings to the thread states defined by the APIs (Thread::getState, JVMTI GetThreadState).  A virtual thread that parkNanos while pinned will park on its carrier, it doesn't unmount and release the carrier.  If some other threads polls the virtual thread state then will see Thread.State.TIMED_WAITING (or state bits that include JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT in the case of JVMTI). So no change to the API, no suggestion whatsoever of exposing "PINNED" in the API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1328266854

From asotona at openjdk.org  Mon Sep 18 08:39:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Sep 2023 08:39:05 GMT
Subject: Integrated: 8294969: Convert jdk.jdeps javap to use the Classfile API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Nov 2022 10:26:31 GMT, Adam Sotona  wrote:

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 1203e11a
Author:    Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/1203e11a8d9b3ef0695282d980ad411213e6aa6c
Stats:     3755 lines in 29 files changed: 920 ins; 1778 del; 1057 mod

8294969: Convert jdk.jdeps javap to use the Classfile API

Reviewed-by: vromero

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

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

From duke at openjdk.org  Mon Sep 18 09:22:58 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Mon, 18 Sep 2023 09:22:58 GMT
Subject: Integrated: 8314236: Overflow in Collections.rotate
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Aug 2023 12:56:46 GMT, Nikita Sakharin  wrote:

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

This pull request has now been integrated.

Changeset: 3828dc91
Author:    Nikita Sakharin <17588081+nikita-sakharin at users.noreply.github.com>
Committer: Aleksey Shipilev 
URL:       https://git.openjdk.org/jdk/commit/3828dc913a3ea28d622b69bd07f26949128eb5f7
Stats:     89 lines in 2 files changed: 85 ins; 1 del; 3 mod

8314236: Overflow in Collections.rotate

Co-authored-by: Nikita Sakharin <17588081+nikita-sakharin at users.noreply.github.com>
Reviewed-by: shade, smarks

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

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

From rpressler at openjdk.org  Mon Sep 18 09:30:47 2023
From: rpressler at openjdk.org (Ron Pressler)
Date: Mon, 18 Sep 2023 09:30:47 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 14 Sep 2023 13:30:28 GMT, Alan Bateman  wrote:

>> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue with debuggers because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
>> 
>> The change is straight-forward with additional state for timed-parking/parked/pinned. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge
>  - Revert back to explicit TIMED_xxx states
>  - Merge
>  - Merge
>  - Merge
>  - Remove unecessary RF from test
>  - Merge
>  - Merge
>  - Remove tab
>  - Cleanup comments
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/9f4b9cea...70b7766d

Marked as reviewed by rpressler (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14978#pullrequestreview-1630626956

From liach at openjdk.org  Mon Sep 18 10:05:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Sep 2023 10:05:41 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 04:11:25 GMT, ???  wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - refactor removing the double !
>  - refactor removing the double !

Marked as reviewed by liach (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/14751#pullrequestreview-1630688748

From redestad at openjdk.org  Mon Sep 18 11:13:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 18 Sep 2023 11:13:46 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v8]
In-Reply-To: 
References: 
 
 
Message-ID: <1-3siia_vUZ4qXHntaiXyohiFmHgCO05CYGT4s0h8Fk=.d262e760-62a3-4be3-ae5e-50cfcfcedb05@github.com>

On Mon, 18 Sep 2023 03:00:25 GMT, Chen Liang  wrote:

>> ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into optimization_for_string_latin1_upper_lower
>>  - Merge branch 'master' into optimization_for_string_latin1_upper_lower
>>  - Merge branch 'master' of github.com:wenshao/jdk into optimization_for_string_latin1_upper_lower
>>  - rename hasNotUpperCaseEx to hasUpperCaseMapping
>>  - rename isLowerCaseEx to hasNotUpperCaseEx
>>  - use hex literal
>>  - add method CharacterDataLatin1#isLowerCaseEx
>>  - remove unnecessary code
>>  - optimization for StringLatin1 UpperLower
>
> src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 93:
> 
>> 91:     }
>> 92: 
>> 93:     boolean hasUpperCaseMapping(int ch) {
> 
> This method is incorrectly named; it actually tests that a char has no upper case mapping. I recommend fixing this by keeping the method name while removing the double `!` at this return and at the if down below to simplify the logic.

I'd have preferred @liach's solution (remove the double negative and keeping the method with name unchanged) but this is OK too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1328567080

From redestad at openjdk.org  Mon Sep 18 11:13:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 18 Sep 2023 11:13:41 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 04:11:25 GMT, ???  wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - refactor removing the double !
>  - refactor removing the double !

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14751#pullrequestreview-1630796696

From lancea at openjdk.org  Mon Sep 18 13:12:31 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 18 Sep 2023 13:12:31 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v6]
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 incrementally with one additional commit since the last revision:

  Revamp isZip64ExtBlockSizeValid

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/f64a70c3..bbc5325d

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

  Stats: 61 lines in 3 files changed: 14 ins; 13 del; 34 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 lancea at openjdk.org  Mon Sep 18 13:17:25 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 18 Sep 2023 13:17:25 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v7]
In-Reply-To: 
References: 
Message-ID: <5i8oE7FeOG7W7B2C5jqyKuGNJ_EHf9POIox606GDhzs=.faa3ffd1-6fa6-4a40-984b-a6557e685c0e@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/bbc5325d..208a5ecc

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 anleonar at redhat.com  Mon Sep 18 13:51:02 2023
From: anleonar at redhat.com (Andrew Leonard)
Date: Mon, 18 Sep 2023 14:51:02 +0100
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
Message-ID: 

Thanks for the clarification Alan.

To ensure the reproducibility of the whole JDK image regardless of the
specific bootjdk used, would it make sense once the "Build JDK" has been
built, we re-build jrt-fs.jar again using the "Build JDK" ? Thus jrt-fs.jar
will be consistent with the rest of the image in terms of what it is
compiled with.

Cheers
Andrew


On Fri, Sep 15, 2023 at 9:49?AM Alan Bateman 
wrote:

> On 15/09/2023 09:09, Andrew Leonard wrote:
> > Hi,
> >
> > jrt-fs.jar is the only jar that is not built (or re-built) with the
> > "Build JDK", and I was wondering why?
> >
>
> The JAR file contains the "jrt" file system provider for the runtime.
> IDE or other tools running on JDK 8/11/etc. need to be able to create a
> FileSystem to access the classes/resources in the run-time image. These
> classes are loaded from that JAR file.
>
> -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rriggs at openjdk.org  Mon Sep 18 13:53:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Sep 2023 13:53:48 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 4 Sep 2023 06:50:18 GMT, ???  wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request with a new target base 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' of github.com:wenshao/jdk into optimization_for_string_latin1_upper_lower
>  - rename hasNotUpperCaseEx to hasUpperCaseMapping
>  - rename isLowerCaseEx to hasNotUpperCaseEx
>  - use hex literal
>  - add method CharacterDataLatin1#isLowerCaseEx
>  - remove unnecessary code
>  - optimization for StringLatin1 UpperLower

src/java.base/share/classes/java/lang/StringLatin1.java line 423:

> 421:         int first;
> 422:         final int len = value.length;
> 423:         // Now check if there are any characters that need to be changed, or are surrogate

Pre-existing: `, or are surrogate` the mention of surrogate is misleading; this is a latin1 string and cannot contain a surrogate.
Here and in the toLowerCaseEx method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1317681978

From jvernee at openjdk.org  Mon Sep 18 14:17:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 18 Sep 2023 14:17:35 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v21]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 13 Sep 2023 19:43:53 GMT, ExE Boss  wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add missing space + reflow lines
>>  - Fix typo
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java line 311:
> 
>> 309:         };
>> 310: 
>> 311:         CANONICAL_LAYOUTS = Map.ofEntries(
> 
> `LibFallback::wcharSize()` and?other?getters for?`LibFallback.NativeConstants`?fields can?throw an?error when?`LibFallback.SUPPORTED` is?`false` due?to the?`fallbackLinker`?library not?being?present, so?this static?initializer should?be?made into?a?method?instead:
> Suggestion:
> 
>     static final Map CANONICAL_LAYOUTS = initCanonicalLayouts();
> 
>     private static Map initCanonicalLayouts() {
>         if (!isSupported()) {
>             return null;
>         }
> 
>         int wchar_size = LibFallback.wcharSize();
>         MemoryLayout wchartLayout = switch(wchar_size) {
>             case 2 -> JAVA_CHAR; // prefer JAVA_CHAR
>             default -> FFIType.layoutFor(wchar_size);
>         };
> 
>         return Map.ofEntries(

Good catch! I've chosen a slightly different solution though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1328794993

From jvernee at openjdk.org  Mon Sep 18 14:17:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 18 Sep 2023 14:17:30 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
Message-ID: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@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:

  Avoid eager use of LibFallback in FallbackLinker static block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/e68b95c1..1f3248df

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

  Stats: 62 lines in 1 file changed: 26 ins; 24 del; 12 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 duke at openjdk.org  Mon Sep 18 15:00:20 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 15:00:20 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v11]
In-Reply-To: 
References: 
Message-ID: 

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLo...

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

  fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14751/files
  - new: https://git.openjdk.org/jdk/pull/14751/files/3f370b19..a0495227

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

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

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

From redestad at openjdk.org  Mon Sep 18 15:05:45 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 18 Sep 2023 15:05:45 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 15:00:20 GMT, ???  wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

src/java.base/share/classes/java/lang/StringLatin1.java line 602:

> 600:         final int len = value.length;
> 601: 
> 602:         // Now check if there are any characters that need to be changed, or are surrogate

Can you fix this one too for consistency? I'll sponsor either way after some testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1328867679

From djelinski at openjdk.org  Mon Sep 18 15:08:11 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Sep 2023 15:08:11 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly
Message-ID: 

Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.

Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
- the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
- `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.

This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
No new tests. Existing tier1-2 tests continue to pass.

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

Commit messages:
 - Clean up getHomeFromShell32
 - Eager load shell32

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

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

From duke at openjdk.org  Mon Sep 18 15:13:28 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 15:13:28 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v12]
In-Reply-To: 
References: 
Message-ID: <3ruDHrG-nb1uNFyGLR6jJOSGytuGRnKXVy_6cNEl2s0=.4c306478-f9cc-49bb-970f-0d53c0ce51ee@github.com>

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLo...

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

  fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14751/files
  - new: https://git.openjdk.org/jdk/pull/14751/files/a0495227..397d49fb

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

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

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

From duke at openjdk.org  Mon Sep 18 15:44:57 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 15:44:57 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
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.

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

Commit messages:
 - restore toLowHexDigit & toHighHexDigit
 - remove unused import
 - remove AbstractStringBuilder internal method 'appendHex'
 - Remove redundant code in the benchmark
 - optimization for HexFormat.formatHex

Changes: https://git.openjdk.org/jdk/pull/15768/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316426
  Stats: 67 lines in 3 files changed: 54 ins; 4 del; 9 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 redestad at openjdk.org  Mon Sep 18 15:44:59 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 18 Sep 2023 15:44:59 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: 
References: 
Message-ID: 

On Fri, 15 Sep 2023 18:04:29 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.

What numbers do you get with this? 

In my experiments the improvement was either negligible or small enough to hardly matter. I also tried flipping bits similar to what you're doing for uppercasing but saw a net regression from that.

I opted for simplicity in #15991 - a simple cleanup that removed a few tiny lookup-tables and still led to a decent improvement. Going the other direction seems like the wrong move.

Results of an experiment to remove the lookup table use from `StringBuilder::appendHex`:

-p size=512
Benchmark                           (size)  Mode  Cnt  Score   Error  Units
HexFormatBench.appenderLowerCached     512  avgt   15  1,629 ? 0,378  us/op # baseline
HexFormatBench.appenderLowerCached     512  avgt   15  0,222 ? 0,009  us/op # 15768, 7.3x
HexFormatBench.appenderLowerCached     512  avgt   15  0,366 ? 0,002  us/op # no_lookup_tables.diff, 4.5x

-p size=4
Benchmark                           (size)  Mode  Cnt   Score   Error  Units
HexFormatBench.appenderLowerCached       4  avgt    5  26,723 ? 1,042  ns/op
HexFormatBench.appenderLowerCached       4  avgt    5   7,492 ? 0,140  ns/op # 15768, 3.6x
HexFormatBench.appenderLowerCached       4  avgt    5  10,205 ? 0,055  ns/op # no_lookup_tables.diff, 2.6x


Most of the win is from having a loop that is easier for the JIT to optimize; the lookup-table impl is faster than no lookup table in these micros, by a factor that is in the same ballpark as your `format` micro numbers. This on a M1. You might get different numbers.

I'm not convinced 30-100% wins on these micro is worth the increase in cache traffic, and would like to see a deeper analysis of the pros and cons of lookup tables before we go ahead with any optimizations that depend on their use.

The `appendHex` method in `StringBuilder` is interesting, but has other maintainability issues. It's a slippery slope to start adding specialized internal routines to `StringBuilder`, and perhaps there are better ways to model this at a higher level.

no_lookup_table.diff:

diff --git a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java
index 57a16bb769a..70727375c0b 100644
--- a/src/java.base/share/classes/java/lang/AbstractStringBuilder.java
+++ b/src/java.base/share/classes/java/lang/AbstractStringBuilder.java
@@ -1825,6 +1825,15 @@ private final void appendChars(CharSequence s, int off, int end) {
         count += end - off;
     }

+    private static char toHighHexDigit(boolean ucase, int value) {
+        value = (value >> 4) & 0xf;
+        return (char) ((value < 10 ? '0' : ucase ? 'A' : 'a') + value);
+    }
+    private static char toLowHexDigit(boolean ucase, int value) {
+        value = (value) & 0xf;
+        return (char) ((value < 10 ? '0' : ucase ? 'A' : 'a') + value);
+    }
+
     final void appendHex(boolean ucase, byte[] bytes, int fromIndex, int toIndex) {
         Preconditions.checkFromToIndex(fromIndex, toIndex, bytes.length, Preconditions.IOOBE_FORMATTER);

@@ -1832,17 +1841,14 @@ final void appendHex(boolean ucase, byte[] bytes, int fromIndex, int toIndex) {

         int charPos = count;
         for (int i = fromIndex; i < toIndex; ++i) {
-            short packed = HexDigits.digitPair(bytes[i], ucase);
+            byte b = bytes[i];
             if (isLatin1()) {
-                ByteArrayLittleEndian.setShort(
-                        value,
-                        charPos,
-                        packed);
+                StringLatin1.putChar(value, charPos++, toHighHexDigit(ucase, b));
+                StringLatin1.putChar(value, charPos++, toLowHexDigit(ucase, b));
             } else {
-                StringUTF16.putChar(value, charPos, packed & 0xff);
-                StringUTF16.putChar(value, charPos + 1, packed >> 8);
+                StringUTF16.putChar(value, charPos++, toHighHexDigit(ucase, b));
+                StringUTF16.putChar(value, charPos++, toLowHexDigit(ucase, b));
             }
-            charPos += 2;
         }

         count = charPos;

I don't think `appendHex` would make the cut as a public API. I think we would need something with much more general utility for that.

A more high-level idea would be to improve said `String` templates JEP to be able to format more generally into `Appendable`/`StringBuilder`, so that hex, octal - any custom format - can be efficiently appended to a `StringBuilder`. 

BTW, here's a patch on top of #15768 that simplifies `formatHex(Appendable..)` to simply append the result of `formatHex(byte[]...)`:


Benchmark                                              (size)  Mode  Cnt     Score     Error   Units
HexFormatBench.appenderLowerCached                        512  avgt   15     0,202 ?   0,001   us/op
HexFormatBench.formatLowerCached                          512  avgt   15     0,189 ?   0,016   us/op


Same speed. Drawback is that the `appender` becomes allocating but short-lived allocations is one of my least concerns:

```java 
diff --git a/src/java.base/share/classes/java/util/HexFormat.java b/src/java.base/share/classes/java/util/HexFormat.java
index e1d88e3ceb6..68a15307fe0 100644
--- a/src/java.base/share/classes/java/util/HexFormat.java
+++ b/src/java.base/share/classes/java/util/HexFormat.java
@@ -407,38 +407,7 @@ public  A formatHex(A out, byte[] bytes, int fromIndex, in
         int length = toIndex - fromIndex;
         if (length > 0) {
             try {
-                boolean prefixEmpty = prefix.isEmpty();
-                boolean suffixEmpty = suffix.isEmpty();
-                boolean delimiterEmpty = delimiter.isEmpty();
-                if (!prefixEmpty) {
-                    out.append(prefix);
-                }
-                if (suffixEmpty && delimiterEmpty && prefixEmpty) {
-                    if (out instanceof StringBuilder sb) {
-                        jla.appendHex(sb, digitCase == Case.UPPERCASE, bytes, fromIndex, toIndex);
-                    } else {
-                        for (int i = 0; i < length; i++) {
-                            toHexDigits(out, bytes[fromIndex + i]);
-                        }
-                    }
-                } else {
-                    toHexDigits(out, bytes[fromIndex]);
-                    for (int i = 1; i < length; i++) {
-                        if (!suffixEmpty) {
-                            out.append(suffix);
-                        }
-                        if (!delimiterEmpty) {
-                            out.append(delimiter);
-                        }
-                        if (!prefixEmpty) {
-                            out.append(prefix);
-                        }
-                        toHexDigits(out, bytes[fromIndex + i]);
-                    }
-                }
-                if (!suffixEmpty) {
-                    out.append(suffix);
-                }
+                out.append(formatHex(bytes, fromIndex, toIndex));
             } catch (IOException ioe) {
                 throw new UncheckedIOException(ioe.getMessage(), ioe);
             }

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1721672736
PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1721851723
PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1722048682

From liach at openjdk.org  Mon Sep 18 15:44:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Sep 2023 15:44:58 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: 
References: 
Message-ID: 

On Fri, 15 Sep 2023 18:04:29 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.

Marked as reviewed by liach (Author).

I have created a JBS issue including the 2 confirmed performance improvements in this patch: https://bugs.openjdk.org/browse/JDK-8316426

src/java.base/share/classes/java/util/HexFormat.java line 410:

> 408:         if (length > 0) {
> 409:             try {
> 410:                 String s = formatOptDelimiter(bytes, fromIndex, toIndex);

Great cleanup over here ???

src/java.base/share/classes/java/util/HexFormat.java line 422:

> 420:                         toHexDigits(out, bytes[fromIndex + i]);
> 421:                     }
> 422:                     out.append(suffix);

Maybe change this whole `else` block to

                    for (int i = 0; i < length; i++) {
                        if (i > 0)
                            out.append(delimiter);
                        out.append(prefix);
                        toHexDigits(out, bytes[fromIndex + i]);
                        out.append(suffix);
                    }

for clarity?

src/java.base/share/classes/java/util/HexFormat.java line 664:

> 662:     public char toHighHexDigit(int value) {
> 663:         value = (value >> 4) & 0xf;
> 664:         return (char) ((value < 10 ? '0' : hexBase) + value);

These changes seem to be the reason `toHexDigitsLong` consistently sees a slight performance drop. Can any professional engineer explain why the old version, which would be like `(char) (value < 10 ? '0' + value : hexBase + value)`, is slightly faster?

Since the effect of this change `hexBase` is not clear, I recommend dropping this for now (remove the field and changes to the 2 methods).

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

PR Review: https://git.openjdk.org/jdk/pull/15768#pullrequestreview-1631092880
PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1723515203
PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1328749231
PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1328748386
PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1328763175

From duke at openjdk.org  Mon Sep 18 15:45:01 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 15:45:01 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: 
References: 
Message-ID: <8_s_QemlqUYrlWpyP1gu8s36PMChNdTfgbxHDHb4IlA=.99958ce3-948b-4aae-89d9-a14fd1eb2393@github.com>

On Fri, 15 Sep 2023 18:04:29 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.

The performance test results are as follows:

## 0. sciprt

bash configure
make images
sh make/devkit/createJMHBundle.sh
bash configure --with-jmh=build/jmh/jars
make test TEST="micro:java.util.HexFormatBench.*"


## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
* cpu : intel xeon sapphire rapids (x64)
* os debian linux


-Benchmark                           (size)  Mode  Cnt  Score   Error  Units (baselinie)
-HexFormatBench.appenderLower           512  avgt   15  2.768 ? 0.034  us/op
-HexFormatBench.appenderLowerCached     512  avgt   15  2.796 ? 0.042  us/op
-HexFormatBench.appenderUpper           512  avgt   15  2.800 ? 0.032  us/op
-HexFormatBench.appenderUpperCached     512  avgt   15  2.781 ? 0.018  us/op
-HexFormatBench.formatLower             512  avgt   15  0.544 ? 0.002  us/op
-HexFormatBench.formatLowerCached       512  avgt   15  0.548 ? 0.004  us/op
-HexFormatBench.formatUpper             512  avgt   15  0.546 ? 0.007  us/op
-HexFormatBench.formatUpperCached       512  avgt   15  0.550 ? 0.005  us/op
-HexFormatBench.toHexDigitsByte         512  avgt   15  3.364 ? 0.015  us/op
-HexFormatBench.toHexDigitsInt          512  avgt   15  3.770 ? 0.017  us/op
-HexFormatBench.toHexDigitsLong         512  avgt   15  4.990 ? 0.018  us/op
-HexFormatBench.toHexDigitsShort        512  avgt   15  3.466 ? 0.017  us/op
-HexFormatBench.toHexLower              512  avgt   15  0.415 ? 0.005  us/op
-HexFormatBench.toHexLowerCached        512  avgt   15  0.422 ? 0.005  us/op
-HexFormatBench.toHexUpper              512  avgt   15  0.413 ? 0.005  us/op
-HexFormatBench.toHexUpperCached        512  avgt   15  0.423 ? 0.004  us/op

+Benchmark                           (size)  Mode  Cnt  Score    Error  Units (optimized)
+HexFormatBench.appenderLower           512  avgt   15  0.163 ?  0.001  us/op (+1598.16)
+HexFormatBench.appenderLowerCached     512  avgt   15  0.161 ?  0.001  us/op (+1636.65)
+HexFormatBench.appenderUpper           512  avgt   15  0.251 ?  0.023  us/op (+1015.54)
+HexFormatBench.appenderUpperCached     512  avgt   15  0.266 ?  0.001  us/op (+945.49)
+HexFormatBench.formatLower             512  avgt   15  0.275 ?  0.001  us/op (+97.82)
+HexFormatBench.formatLowerCached       512  avgt   15  0.277 ?  0.001  us/op (+97.84)
+HexFormatBench.formatUpper             512  avgt   15  0.285 ?  0.001  us/op (+91.58)
+HexFormatBench.formatUpperCached       512  avgt   15  0.285 ?  0.001  us/op (+92.99)
+HexFormatBench.toHexDigitsByte         512  avgt   15  3.554 ?  0.028  us/op (-5.35)
+HexFormatBench.toHexDigitsInt          512  avgt   15  3.910 ?  0.015  us/op (-3.59)
+HexFormatBench.toHexDigitsLong         512  avgt   15  5.288 ?  0.018  us/op (-5.64)
+HexFormatBench.toHexDigitsShort        512  avgt   15  3.637 ?  0.012  us/op (-4.71)
+HexFormatBench.toHexLower              512  avgt   15  0.445 ?  0.001  us/op (-6.75)
+HexFormatBench.toHexLowerCached        512  avgt   15  0.442 ?  0.001  us/op (-4.53)
+HexFormatBench.toHexUpper              512  avgt   15  0.445 ?  0.001  us/op (-7.20)
+HexFormatBench.toHexUpperCached        512  avgt   15  0.441 ?  0.001  us/op (-4.09)


## 2. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
* cpu : aliyun yitian 710 (aarch64)
* os debian linux


-Benchmark                           (size)  Mode  Cnt  Score   Error  Units (baseline)
-HexFormatBench.appenderLower           512  avgt   15  2.857 ? 0.791  us/op
-HexFormatBench.appenderLowerCached     512  avgt   15  2.832 ? 0.758  us/op
-HexFormatBench.appenderUpper           512  avgt   15  2.360 ? 0.010  us/op
-HexFormatBench.appenderUpperCached     512  avgt   15  2.361 ? 0.013  us/op
-HexFormatBench.formatLower             512  avgt   15  0.947 ? 0.406  us/op
-HexFormatBench.formatLowerCached       512  avgt   15  0.616 ? 0.002  us/op
-HexFormatBench.formatUpper             512  avgt   15  1.212 ? 0.411  us/op
-HexFormatBench.formatUpperCached       512  avgt   15  0.616 ? 0.001  us/op
-HexFormatBench.toHexDigitsByte         512  avgt   15  5.844 ? 0.264  us/op
-HexFormatBench.toHexDigitsInt          512  avgt   15  7.392 ? 0.207  us/op
-HexFormatBench.toHexDigitsLong         512  avgt   15  8.068 ? 0.303  us/op
-HexFormatBench.toHexDigitsShort        512  avgt   15  6.214 ? 0.266  us/op
-HexFormatBench.toHexLower              512  avgt   15  0.926 ? 0.003  us/op
-HexFormatBench.toHexLowerCached        512  avgt   15  1.000 ? 0.005  us/op
-HexFormatBench.toHexUpper              512  avgt   15  0.927 ? 0.002  us/op
-HexFormatBench.toHexUpperCached        512  avgt   15  0.999 ? 0.020  us/op

+Benchmark                           (size)  Mode  Cnt  Score    Error  Units (optimized)
+HexFormatBench.appenderLower           512  avgt   15  0.356 ?  0.001  us/op (+702.53)
+HexFormatBench.appenderLowerCached     512  avgt   15  0.356 ?  0.001  us/op (+695.51)
+HexFormatBench.appenderUpper           512  avgt   15  0.304 ?  0.001  us/op (+676.32)
+HexFormatBench.appenderUpperCached     512  avgt   15  0.304 ?  0.001  us/op (+676.65)
+HexFormatBench.formatLower             512  avgt   15  0.461 ?  0.001  us/op (+105.43)
+HexFormatBench.formatLowerCached       512  avgt   15  0.485 ?  0.001  us/op (+27.02)
+HexFormatBench.formatUpper             512  avgt   15  0.644 ?  0.003  us/op (+88.20)
+HexFormatBench.formatUpperCached       512  avgt   15  0.595 ?  0.003  us/op (+3.53)
+HexFormatBench.toHexDigitsByte         512  avgt   15  5.804 ?  0.237  us/op (+0.69)
+HexFormatBench.toHexDigitsInt          512  avgt   15  7.209 ?  0.212  us/op (+2.54)
+HexFormatBench.toHexDigitsLong         512  avgt   15  8.301 ?  0.422  us/op (-2.81)
+HexFormatBench.toHexDigitsShort        512  avgt   15  5.908 ?  0.255  us/op (+5.18)
+HexFormatBench.toHexLower              512  avgt   15  0.494 ?  0.001  us/op (+87.45)
+HexFormatBench.toHexLowerCached        512  avgt   15  0.494 ?  0.001  us/op (+102.43)
+HexFormatBench.toHexUpper              512  avgt   15  0.494 ?  0.001  us/op (+87.66)
+HexFormatBench.toHexUpperCached        512  avgt   15  0.493 ?  0.001  us/op (+102.64)


## 3. Mac Book Pro M1 Pro

-Benchmark                           (size)  Mode  Cnt  Score    Error  Units (baseline)
-HexFormatBench.appenderLower           512  avgt   15  2.867 ?  0.035  us/op
-HexFormatBench.appenderLowerCached     512  avgt   15  1.656 ?  0.875  us/op
-HexFormatBench.appenderUpper           512  avgt   15  2.813 ?  0.085  us/op
-HexFormatBench.appenderUpperCached     512  avgt   15  1.575 ?  0.901  us/op
-HexFormatBench.formatLower             512  avgt   15  0.385 ?  0.001  us/op
-HexFormatBench.formatLowerCached       512  avgt   15  0.385 ?  0.002  us/op
-HexFormatBench.formatUpper             512  avgt   15  0.385 ?  0.001  us/op
-HexFormatBench.formatUpperCached       512  avgt   15  0.384 ?  0.001  us/op
-HexFormatBench.toHexDigitsByte         512  avgt   15  1.688 ?  0.009  us/op
-HexFormatBench.toHexDigitsInt          512  avgt   15  2.991 ?  0.015  us/op
-HexFormatBench.toHexDigitsLong         512  avgt   15  3.719 ?  0.081  us/op
-HexFormatBench.toHexDigitsShort        512  avgt   15  1.868 ?  0.010  us/op
-HexFormatBench.toHexLower              512  avgt   15  0.321 ?  0.001  us/op
-HexFormatBench.toHexLowerCached        512  avgt   15  0.322 ?  0.001  us/op
-HexFormatBench.toHexUpper              512  avgt   15  0.324 ?  0.001  us/op
-HexFormatBench.toHexUpperCached        512  avgt   15  0.325 ?  0.001  us/op

+Benchmark                           (size)  Mode  Cnt  Score    Error  Units (optimized)
+HexFormatBench.appenderLower           512  avgt   15  0.212 ?  0.003  us/op (+1252.36)
+HexFormatBench.appenderLowerCached     512  avgt   15  0.211 ?  0.001  us/op (+684.84)
+HexFormatBench.appenderUpper           512  avgt   15  0.199 ?  0.002  us/op (+1313.57)
+HexFormatBench.appenderUpperCached     512  avgt   15  0.198 ?  0.001  us/op (+695.46)
+HexFormatBench.formatLower             512  avgt   15  0.221 ?  0.001  us/op (+74.21)
+HexFormatBench.formatLowerCached       512  avgt   15  0.192 ?  0.001  us/op (+100.53)
+HexFormatBench.formatUpper             512  avgt   15  0.317 ?  0.002  us/op (+21.46)
+HexFormatBench.formatUpperCached       512  avgt   15  0.348 ?  0.003  us/op (+10.35)
+HexFormatBench.toHexDigitsByte         512  avgt   15  1.715 ?  0.011  us/op (-1.58)
+HexFormatBench.toHexDigitsInt          512  avgt   15  2.261 ?  0.012  us/op (+32.29)
+HexFormatBench.toHexDigitsLong         512  avgt   15  3.776 ?  0.023  us/op (-1.51)
+HexFormatBench.toHexDigitsShort        512  avgt   15  1.862 ?  0.011  us/op (+0.33)
+HexFormatBench.toHexLower              512  avgt   15  0.289 ?  0.004  us/op (+11.08)
+HexFormatBench.toHexLowerCached        512  avgt   15  0.294 ?  0.002  us/op (+9.53)
+HexFormatBench.toHexUpper              512  avgt   15  0.288 ?  0.001  us/op (+12.50)
+HexFormatBench.toHexUpperCached        512  avgt   15  0.295 ?  0.001  us/op (+10.17)

Add internal methods to StringBuilder for performance optimization, I saw that the implementation of JEP 403 String Template does similar things.


class AbstractStringBuilder {
    long mix(long lengthCoder) { }
    long prepend(long lengthCoder, byte[] buffer) {}
    // ...
}


However, the StringBuilder.appendHex method can have more usage scenarios and can be considered as a public method. Is it necessary to submit a new PR to add these methods?


class AbstractStringBuilder {
    public void appendHex(byte[] bytes) {}
    public void appendHex(byte[] bytes, boolean ucase) {}
    public void appendHex(byte[] bytes, int fromIndex, int toIndex) {}
    public void appendHex(byte[] bytes, int fromIndex, int toIndex, boolean ucase) {}
}



Regarding the performance of using lookup table, I think it makes sense when the length of byte[] is greater than 8. I think that when the length of byte[] is actually used, there is a high probability that it will be greater than 8. Of course, I just said the number 8 casually, it could be 12, or 16.

HexDecimal#DIGITS is a table with a size of 512 bytes. I think that in such a table, when it needs to be used continuously, it is worthwhile to perform table lookup operations.

I deleted the newly added AbstractBuilder.appendHex method, Such changes are reduced and performance improvements are similar.

The new performance test results are as follows:

## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
* cpu : intel xeon sapphire rapids (x64)
* os debian linux


-Benchmark                           (size)  Mode  Cnt  Score   Error  Units (baselinie)
-HexFormatBench.appenderLower           512  avgt   15  2.768 ? 0.034  us/op
-HexFormatBench.appenderLowerCached     512  avgt   15  2.796 ? 0.042  us/op
-HexFormatBench.appenderUpper           512  avgt   15  2.800 ? 0.032  us/op
-HexFormatBench.appenderUpperCached     512  avgt   15  2.781 ? 0.018  us/op
-HexFormatBench.formatLower             512  avgt   15  0.544 ? 0.002  us/op
-HexFormatBench.formatLowerCached       512  avgt   15  0.548 ? 0.004  us/op
-HexFormatBench.formatUpper             512  avgt   15  0.546 ? 0.007  us/op
-HexFormatBench.formatUpperCached       512  avgt   15  0.550 ? 0.005  us/op
-HexFormatBench.toHexDigitsByte         512  avgt   15  3.364 ? 0.015  us/op
-HexFormatBench.toHexDigitsInt          512  avgt   15  3.770 ? 0.017  us/op
-HexFormatBench.toHexDigitsLong         512  avgt   15  4.990 ? 0.018  us/op
-HexFormatBench.toHexDigitsShort        512  avgt   15  3.466 ? 0.017  us/op
-HexFormatBench.toHexLower              512  avgt   15  0.415 ? 0.005  us/op
-HexFormatBench.toHexLowerCached        512  avgt   15  0.422 ? 0.005  us/op
-HexFormatBench.toHexUpper              512  avgt   15  0.413 ? 0.005  us/op
-HexFormatBench.toHexUpperCached        512  avgt   15  0.423 ? 0.004  us/op

+Benchmark                           (size)  Mode  Cnt  Score    Error  Units (optimized)
+HexFormatBench.appenderLower           512  avgt   15  0.211 ?  0.002  us/op (+1211.85)
+HexFormatBench.appenderLowerCached     512  avgt   15  0.210 ?  0.004  us/op (+1231.43)
+HexFormatBench.appenderUpper           512  avgt   15  0.289 ?  0.002  us/op (+868.86)
+HexFormatBench.appenderUpperCached     512  avgt   15  0.296 ?  0.019  us/op (+839.53)
+HexFormatBench.formatLower             512  avgt   15  0.265 ?  0.001  us/op (+105.29)
+HexFormatBench.formatLowerCached       512  avgt   15  0.267 ?  0.002  us/op (+105.25)
+HexFormatBench.formatUpper             512  avgt   15  0.274 ?  0.002  us/op (+99.28)
+HexFormatBench.formatUpperCached       512  avgt   15  0.286 ?  0.019  us/op (+92.31)
+HexFormatBench.toHexDigitsByte         512  avgt   15  3.351 ?  0.011  us/op (+0.39)
+HexFormatBench.toHexDigitsInt          512  avgt   15  3.708 ?  0.011  us/op (+1.68)
+HexFormatBench.toHexDigitsLong         512  avgt   15  5.051 ?  0.014  us/op (-1.21)
+HexFormatBench.toHexDigitsShort        512  avgt   15  3.456 ?  0.012  us/op (+0.29)
+HexFormatBench.toHexLower              512  avgt   15  0.445 ?  0.001  us/op (-6.75)
+HexFormatBench.toHexLowerCached        512  avgt   15  0.441 ?  0.001  us/op (-4.31)
+HexFormatBench.toHexUpper              512  avgt   15  0.444 ?  0.001  us/op (-6.99)
+HexFormatBench.toHexUpperCached        512  avgt   15  0.441 ?  0.001  us/op (-4.09)


## 2. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
* cpu : aliyun yitian 710 (aarch64)
* os debian linux


-Benchmark                           (size)  Mode  Cnt  Score   Error  Units (baseline)
-HexFormatBench.appenderLower           512  avgt   15  2.857 ? 0.791  us/op
-HexFormatBench.appenderLowerCached     512  avgt   15  2.832 ? 0.758  us/op
-HexFormatBench.appenderUpper           512  avgt   15  2.360 ? 0.010  us/op
-HexFormatBench.appenderUpperCached     512  avgt   15  2.361 ? 0.013  us/op
-HexFormatBench.formatLower             512  avgt   15  0.947 ? 0.406  us/op
-HexFormatBench.formatLowerCached       512  avgt   15  0.616 ? 0.002  us/op
-HexFormatBench.formatUpper             512  avgt   15  1.212 ? 0.411  us/op
-HexFormatBench.formatUpperCached       512  avgt   15  0.616 ? 0.001  us/op
-HexFormatBench.toHexDigitsByte         512  avgt   15  5.844 ? 0.264  us/op
-HexFormatBench.toHexDigitsInt          512  avgt   15  7.392 ? 0.207  us/op
-HexFormatBench.toHexDigitsLong         512  avgt   15  8.068 ? 0.303  us/op
-HexFormatBench.toHexDigitsShort        512  avgt   15  6.214 ? 0.266  us/op
-HexFormatBench.toHexLower              512  avgt   15  0.926 ? 0.003  us/op
-HexFormatBench.toHexLowerCached        512  avgt   15  1.000 ? 0.005  us/op
-HexFormatBench.toHexUpper              512  avgt   15  0.927 ? 0.002  us/op
-HexFormatBench.toHexUpperCached        512  avgt   15  0.999 ? 0.020  us/op

+Benchmark                           (size)  Mode  Cnt  Score    Error  Units (optimized)
+HexFormatBench.appenderLower           512  avgt   15  0.343 ?  0.001  us/op (+732.95)
+HexFormatBench.appenderLowerCached     512  avgt   15  0.345 ?  0.001  us/op (+720.87)
+HexFormatBench.appenderUpper           512  avgt   15  0.352 ?  0.002  us/op (+570.46)
+HexFormatBench.appenderUpperCached     512  avgt   15  0.349 ?  0.001  us/op (+576.51)
+HexFormatBench.formatLower             512  avgt   15  0.464 ?  0.001  us/op (+104.10)
+HexFormatBench.formatLowerCached       512  avgt   15  0.484 ?  0.002  us/op (+27.28)
+HexFormatBench.formatUpper             512  avgt   15  0.650 ?  0.001  us/op (+86.47)
+HexFormatBench.formatUpperCached       512  avgt   15  0.598 ?  0.001  us/op (+3.02)
+HexFormatBench.toHexDigitsByte         512  avgt   15  5.591 ?  0.058  us/op (+4.53)
+HexFormatBench.toHexDigitsInt          512  avgt   15  7.080 ?  0.114  us/op (+4.41)
+HexFormatBench.toHexDigitsLong         512  avgt   15  7.754 ?  0.040  us/op (+4.05)
+HexFormatBench.toHexDigitsShort        512  avgt   15  5.779 ?  0.076  us/op (+7.53)
+HexFormatBench.toHexLower              512  avgt   15  0.494 ?  0.001  us/op (+87.45)
+HexFormatBench.toHexLowerCached        512  avgt   15  0.493 ?  0.001  us/op (+102.84)
+HexFormatBench.toHexUpper              512  avgt   15  0.494 ?  0.001  us/op (+87.66)
+HexFormatBench.toHexUpperCached        512  avgt   15  0.493 ?  0.001  us/op (+102.64)


## 3. Mac Book Pro M1 Pro

-Benchmark                           (size)  Mode  Cnt  Score    Error  Units (baseline)
-HexFormatBench.appenderLower           512  avgt   15  2.867 ?  0.035  us/op
-HexFormatBench.appenderLowerCached     512  avgt   15  1.656 ?  0.875  us/op
-HexFormatBench.appenderUpper           512  avgt   15  2.813 ?  0.085  us/op
-HexFormatBench.appenderUpperCached     512  avgt   15  1.575 ?  0.901  us/op
-HexFormatBench.formatLower             512  avgt   15  0.385 ?  0.001  us/op
-HexFormatBench.formatLowerCached       512  avgt   15  0.385 ?  0.002  us/op
-HexFormatBench.formatUpper             512  avgt   15  0.385 ?  0.001  us/op
-HexFormatBench.formatUpperCached       512  avgt   15  0.384 ?  0.001  us/op
-HexFormatBench.toHexDigitsByte         512  avgt   15  1.688 ?  0.009  us/op
-HexFormatBench.toHexDigitsInt          512  avgt   15  2.991 ?  0.015  us/op
-HexFormatBench.toHexDigitsLong         512  avgt   15  3.719 ?  0.081  us/op
-HexFormatBench.toHexDigitsShort        512  avgt   15  1.868 ?  0.010  us/op
-HexFormatBench.toHexLower              512  avgt   15  0.321 ?  0.001  us/op
-HexFormatBench.toHexLowerCached        512  avgt   15  0.322 ?  0.001  us/op
-HexFormatBench.toHexUpper              512  avgt   15  0.324 ?  0.001  us/op
-HexFormatBench.toHexUpperCached        512  avgt   15  0.325 ?  0.001  us/op

+Benchmark                           (size)  Mode  Cnt  Score    Error  Units (optimized)
+HexFormatBench.appenderLower           512  avgt   15  0.207 ?  0.001  us/op (+1285.03)
+HexFormatBench.appenderLowerCached     512  avgt   15  0.206 ?  0.001  us/op (+703.89)
+HexFormatBench.appenderUpper           512  avgt   15  0.225 ?  0.001  us/op (+1150.23)
+HexFormatBench.appenderUpperCached     512  avgt   15  0.225 ?  0.001  us/op (+600.00)
+HexFormatBench.formatLower             512  avgt   15  0.211 ?  0.003  us/op (+82.47)
+HexFormatBench.formatLowerCached       512  avgt   15  0.186 ?  0.001  us/op (+106.99)
+HexFormatBench.formatUpper             512  avgt   15  0.312 ?  0.001  us/op (+23.40)
+HexFormatBench.formatUpperCached       512  avgt   15  0.344 ?  0.001  us/op (+11.63)
+HexFormatBench.toHexDigitsByte         512  avgt   15  1.718 ?  0.054  us/op (-1.75)
+HexFormatBench.toHexDigitsInt          512  avgt   15  2.255 ?  0.010  us/op (+32.64)
+HexFormatBench.toHexDigitsLong         512  avgt   15  3.764 ?  0.005  us/op (-1.20)
+HexFormatBench.toHexDigitsShort        512  avgt   15  1.858 ?  0.008  us/op (+0.54)
+HexFormatBench.toHexLower              512  avgt   15  0.289 ?  0.004  us/op (+11.08)
+HexFormatBench.toHexLowerCached        512  avgt   15  0.295 ?  0.001  us/op (+9.16)
+HexFormatBench.toHexUpper              512  avgt   15  0.288 ?  0.001  us/op (+12.50)
+HexFormatBench.toHexUpperCached        512  avgt   15  0.297 ?  0.005  us/op (+9.43)

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1721723317
PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1721944547
PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1722180550

From duke at openjdk.org  Mon Sep 18 15:45:02 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 15:45:02 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: 
References: 
 
Message-ID: <9wi2sISde1_tMxSbzhs3qow1_5_JEwRB5_Hvn6H8gg8=.b75b2f9e-75bf-4d24-a046-bcd45cb04f19@github.com>

On Fri, 15 Sep 2023 18:20:32 GMT, Claes Redestad  wrote:

> What numbers do you get with this?
> 
> In my experiments the improvement was either negligible or small enough to hardly matter. I also tried flipping bits similar to what you're doing for uppercasing but saw a net regression from that.
> 
> I opted for simplicity in #15991 - a simple cleanup that removed a few tiny lookup-tables and still led to a decent improvement. Going the other direction seems like the wrong move.

The byte[] length used by HexFormatBench is 512. In this scenario, the performance improvement of using table lookup is significant.

> I don't think `appendHex` would make the cut as a public API. I think we would need something with much more general utility for that.
> 
> A more high-level idea would be to improve said `String` templates JEP to be able to format more generally into `Appendable`/`StringBuilder`, so that hex, octal - any custom format - can be efficiently appended to a `StringBuilder`. 
> 
> BTW, here's a patch on top of #15768 that simplifies `formatHex(Appendable..)` to simply append the result of `formatHex(byte[]...)`:
> 
> 
> Benchmark                                              (size)  Mode  Cnt     Score     Error   Units
> HexFormatBench.appenderLowerCached                        512  avgt   15     0,202 ?   0,001   us/op
> HexFormatBench.formatLowerCached                          512  avgt   15     0,189 ?   0,016   us/op
> 
> 
> Same speed. Drawback is that the `appender` becomes allocating but short-lived allocations is one of my least concerns:
> 
> ```java 
> diff --git a/src/java.base/share/classes/java/util/HexFormat.java b/src/java.base/share/classes/java/util/HexFormat.java
> index e1d88e3ceb6..68a15307fe0 100644
> --- a/src/java.base/share/classes/java/util/HexFormat.java
> +++ b/src/java.base/share/classes/java/util/HexFormat.java
> @@ -407,38 +407,7 @@ public  A formatHex(A out, byte[] bytes, int fromIndex, in
>          int length = toIndex - fromIndex;
>          if (length > 0) {
>              try {
> -                boolean prefixEmpty = prefix.isEmpty();
> -                boolean suffixEmpty = suffix.isEmpty();
> -                boolean delimiterEmpty = delimiter.isEmpty();
> -                if (!prefixEmpty) {
> -                    out.append(prefix);
> -                }
> -                if (suffixEmpty && delimiterEmpty && prefixEmpty) {
> -                    if (out instanceof StringBuilder sb) {
> -                        jla.appendHex(sb, digitCase == Case.UPPERCASE, bytes, fromIndex, toIndex);
> -                    } else {
> -                        for (int i = 0; i < length; i++) {
> -                            toHexDigits(out, bytes[fromIndex + i]);
> -                        }
> -                    }
> -                } else {
> -                    toHexDigits(out, bytes[fromIndex]);
> -                    for (int i = 1; i < length; i++) {
> -                        if (!suffixEmpty) {
> -                            out.append(suffix);
> -                        }
> -                        if (!delimiterEmpty) {
> -                            out.append(delimiter);
> -                 ...

@cl4es Can you help me create an issue for this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1721726615
PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1722356329

From redestad at openjdk.org  Mon Sep 18 15:45:03 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 18 Sep 2023 15:45:03 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: <9wi2sISde1_tMxSbzhs3qow1_5_JEwRB5_Hvn6H8gg8=.b75b2f9e-75bf-4d24-a046-bcd45cb04f19@github.com>
References: 
 
 <9wi2sISde1_tMxSbzhs3qow1_5_JEwRB5_Hvn6H8gg8=.b75b2f9e-75bf-4d24-a046-bcd45cb04f19@github.com>
Message-ID: 

On Fri, 15 Sep 2023 19:11:48 GMT, ???  wrote:

> The byte[] length used by HexFormatBench is 512. In this scenario, the performance improvement of using table lookup is significant.

Is this a common use-case? I could see an argument that formatting small chunks is much more common, where users will experience relatively more cache misses from the table lookup.

The gain from specializing for `StringBuilder` is impressive. My guess is that most of the gain is from enabling better loop optimizations by turning a complicated loop with interface calls into a simple counted loop over a byte[]. This could be split out into a separate PR, or perhaps we could consider more generalizable approaches to make `append` and `format` perform at the same level

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1721772711

From redestad at openjdk.org  Mon Sep 18 15:45:05 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 18 Sep 2023 15:45:05 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 13:51:06 GMT, Chen Liang  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.
>
> src/java.base/share/classes/java/util/HexFormat.java line 664:
> 
>> 662:     public char toHighHexDigit(int value) {
>> 663:         value = (value >> 4) & 0xf;
>> 664:         return (char) ((value < 10 ? '0' : hexBase) + value);
> 
> These changes seem to be the reason `toHexDigitsLong` consistently sees a slight performance drop. Can any professional engineer explain why the old version, which would be like `(char) (value < 10 ? '0' + value : hexBase + value)`, is slightly faster?
> 
> Since the effect of this change `hexBase` is not clear, I recommend dropping this for now (remove the field and changes to the 2 methods).

Yes, please drop this. Possibly re-attempting it in a future PR, though I'm a bit skeptical of the potential win here.

I did test something like `hexBase + value` in #15591 to a similar effect, so opted for just storing `digitCase`. My best guess as to why are that the JIT is simply better at (or more eager to) eliminating untaken paths than it is at constant fold the field load. Or the branch isn't eliminated and we're seeing the effect of branch prediction. I'd recommend analyzing the asm generated (via e.g. `-prof perfasm`) to understand this in depth

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1328842647

From jvernee at openjdk.org  Mon Sep 18 15:45:39 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 18 Sep 2023 15:45:39 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeli?ski  wrote:

> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
> 
> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
> 
> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
> No new tests. Existing tier1-2 tests continue to pass.

Okay, if my reading of this is correct: the delay loading was done because `SHGetKnownFolderPath` is not available before Vista, so when accessing the function we can catch the exception and try  `SHGetFolderPath` instead. So, this mechanism is safe to remove if we no longer support Windows XP/2000. I'm not sure what the policy on that is though.

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

PR Comment: https://git.openjdk.org/jdk/pull/15789#issuecomment-1723746516

From djelinski at openjdk.org  Mon Sep 18 16:08:39 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Sep 2023 16:08:39 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeli?ski  wrote:

> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
> 
> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
> 
> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
> No new tests. Existing tier1-2 tests continue to pass.

Well yes, if `SHGetKnownFolderPath` were available in Win2k, delayload would probably have been removed in 3b0f760747ae66cdd343a5e1d623af65e089b442.

Oracle docs state that JDK17 only supports Win8 and newer:
https://www.oracle.com/java/technologies/javase/products-doc-jdk17certconfig.html

We recently integrated a change that requires Vista or newer:
[JDK-8302659](https://bugs.openjdk.org/browse/JDK-8302659)

During compilation we enable APIs from Win8:
https://github.com/openjdk/jdk/blob/2e2d49c76d7bb43a431b5c4f2552beef8798258b/make/autoconf/flags-cflags.m4#L494

based on the above, I believe we can ignore WinXP compatibility here.

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

PR Comment: https://git.openjdk.org/jdk/pull/15789#issuecomment-1723814098

From mchung at openjdk.org  Mon Sep 18 16:46:00 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 18 Sep 2023 16:46:00 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v12]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sun, 17 Sep 2023 07:42:43 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/java/lang/StackFrameInfo.java line 93:
>> 
>>> 91:         synchronized (this) {
>>> 92:             if (type instanceof String sig) {
>>> 93:                 type = JLIA.getMethodType(sig, declaringClass().getClassLoader());
>> 
>> Maybe?there should?be a?`return`?here:
>> Suggestion:
>> 
>>                 return type = JLIA.getMethodType(sig, declaringClass().getClassLoader());
>
> `type` is of type `Object`, don't think this compiles as the result type of `=` is the `type` variable's type.

You missed line 96 where `type` is returned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1329010705

From jvernee at openjdk.org  Mon Sep 18 16:53:39 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 18 Sep 2023 16:53:39 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 16:05:37 GMT, Daniel Jeli?ski  wrote:

> based on the above, I believe we can ignore WinXP compatibility here.

I tend to agree.

> During compilation we enable APIs from Win8:

This is interesting. I think that means the `define` at the start of src/java.base/windows/native/libjava/java_props_md.c can also be removed

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

PR Comment: https://git.openjdk.org/jdk/pull/15789#issuecomment-1723942789

From duke at openjdk.org  Mon Sep 18 17:07:54 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 18 Sep 2023 17:07:54 GMT
Subject: Integrated: 8311220: Optimization for StringLatin UpperLower
In-Reply-To: 
References: 
Message-ID: 

On Mon, 3 Jul 2023 04:02:44 GMT, ???  wrote:

> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.StringUpperLower.*"
> 
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
> 
> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
> +StringUpperLower.lowerToLo...

This pull request has now been integrated.

Changeset: f09b7af6
Author:    shaojin.wensj 
Committer: Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/f09b7af6851c725b0fc4d63832b52e17c4d24836
Stats:     14 lines in 1 file changed: 1 ins; 7 del; 6 mod

8311220: Optimization for StringLatin UpperLower

Reviewed-by: redestad, liach

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

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

From duke at openjdk.org  Mon Sep 18 17:17:01 2023
From: duke at openjdk.org (duke)
Date: Mon, 18 Sep 2023 17:17:01 GMT
Subject: Withdrawn: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
Message-ID: 

On Mon, 19 Dec 2022 11:26:25 GMT, Romain Manni-Bucau  wrote:

> enumeration(list) will create an enumeration, a list and an iterator whereas the impl only requires an iterator
> this PR drops the enumeration wrapper for binary constructor and just maps the enumeration to an iterator for the other case which should be a better compromise in practise.
> 
> Another side but nice effect is to have some lighter classloading (subgraph)

This pull request has been closed without being integrated.

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

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

From rriggs at openjdk.org  Mon Sep 18 17:21:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Sep 2023 17:21:42 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: <8_s_QemlqUYrlWpyP1gu8s36PMChNdTfgbxHDHb4IlA=.99958ce3-948b-4aae-89d9-a14fd1eb2393@github.com>
References: 
 <8_s_QemlqUYrlWpyP1gu8s36PMChNdTfgbxHDHb4IlA=.99958ce3-948b-4aae-89d9-a14fd1eb2393@github.com>
Message-ID: 

On Fri, 15 Sep 2023 22:19:53 GMT, ???  wrote:

> HexDecimal#DIGITS is a table with a size of 512 bytes. I think that in such a table, when it needs to be used continuously, it is worthwhile to perform table lookup operations.

HexFormat was designed for presenting bytes to humans, typical line lengths for the useful output are 80-130 characters, so input sizes of 40-65 bytes, probably less when other interpretations (such as latin1 or ascii) are appended.
And the output is not typically performance sensitive. Please keep the code small and easy to maintain.

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1724036912

From djelinski at openjdk.org  Mon Sep 18 18:10:13 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Sep 2023 18:10:13 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeli?ski  wrote:

> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
> 
> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
> 
> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
> No new tests. Existing tier1-2 tests continue to pass.

Hmm, indeed `VER_PLATFORM_WIN32_WINDOWS` was not used... Removed now. Was that the `define` you were referring to?

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

PR Comment: https://git.openjdk.org/jdk/pull/15789#issuecomment-1724121895

From djelinski at openjdk.org  Mon Sep 18 18:10:12 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Sep 2023 18:10:12 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
> 
> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
> 
> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
> No new tests. Existing tier1-2 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused define

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15789/files
  - new: https://git.openjdk.org/jdk/pull/15789/files/abf04a13..1fa01288

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

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

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

From erikj at openjdk.org  Mon Sep 18 18:12:41 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 18 Sep 2023 18:12:41 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 16:56:48 GMT, Naoto Sato  wrote:

>> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 

make/modules/java.base/gensrc/GensrcRegex.gmk line 35:

> 33: INDICCONJUNCTBREAKTEMP = $(MODULE_SRC)/share/classes/jdk/internal/util/regex/IndicConjunctBreak.java.template
> 34: INDICCONJUNCTBREAKPROPS = $(MODULE_SRC)/share/data/unicodedata/DerivedCoreProperties.txt
> 35: INDICCONJUNCTBREAKPARAMS = InCB\=Linker InCB\=Extend InCB\=Consonant

Please use `:=` for assignment unless you explicitly need lazy evaluation for these variables. I can't see any reason to need that here.

I don't think you need to escape `=`. What happens if you don't?

make/modules/java.base/gensrc/GensrcRegex.gmk line 44:

> 42: 		$(INDICCONJUNCTBREAKPROPS) \
> 43: 		$(GENSRC_INDICCONJUNCTBREAK) \
> 44: 		$(INDICCONJUNCTBREAKPARAMS)

Please use 4 spaces after the initial tab for continuation indentation in recipes (see point 2 and 6 https://openjdk.org/groups/build/doc/code-conventions.html).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1329103285
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1329105914

From jvernee at openjdk.org  Mon Sep 18 18:27:38 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 18 Sep 2023 18:27:38 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 18:05:19 GMT, Daniel Jeli?ski  wrote:

> Hmm, indeed `VER_PLATFORM_WIN32_WINDOWS` was not used... Removed now. Was that the `define` you were referring to?

Err, sorry, I was talking about the `_WIN32_NT` define, but that was actually already removed in https://github.com/openjdk/jdk/commit/4fd79a6ad2683e4863bd4e311cb01cbc30ebf57f#diff-e17e04444071ba72ceac86556f300573321b4317b88bbd694e55f51031b7e3db

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

PR Comment: https://git.openjdk.org/jdk/pull/15789#issuecomment-1724149067

From naoto at openjdk.org  Mon Sep 18 18:33:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Sep 2023 18:33:26 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 18 Sep 2023 18:04:22 GMT, Erik Joelsson  wrote:

>> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>>    
>>    Co-authored-by: Andrey Turbanov 
>>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>>    
>>    Co-authored-by: Andrey Turbanov 
>
> make/modules/java.base/gensrc/GensrcRegex.gmk line 35:
> 
>> 33: INDICCONJUNCTBREAKTEMP = $(MODULE_SRC)/share/classes/jdk/internal/util/regex/IndicConjunctBreak.java.template
>> 34: INDICCONJUNCTBREAKPROPS = $(MODULE_SRC)/share/data/unicodedata/DerivedCoreProperties.txt
>> 35: INDICCONJUNCTBREAKPARAMS = InCB\=Linker InCB\=Extend InCB\=Consonant
> 
> Please use `:=` for assignment unless you explicitly need lazy evaluation for these variables. I can't see any reason to need that here.
> 
> I don't think you need to escape `=`. What happens if you don't?

You are correct on both. Fixed.

> make/modules/java.base/gensrc/GensrcRegex.gmk line 44:
> 
>> 42: 		$(INDICCONJUNCTBREAKPROPS) \
>> 43: 		$(GENSRC_INDICCONJUNCTBREAK) \
>> 44: 		$(INDICCONJUNCTBREAKPARAMS)
> 
> Please use 4 spaces after the initial tab for continuation indentation in recipes (see point 2 and 6 https://openjdk.org/groups/build/doc/code-conventions.html).

I wasn't aware of the convention (initial tab, then spaces for further indentation). Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1329126852
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1329126899

From naoto at openjdk.org  Mon Sep 18 18:33:20 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Sep 2023 18:33:20 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Fix GensrcRegex.gmk
 - Merge branch 'master' into JDK-8296246-Unicode15.1
 - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
   
   Co-authored-by: Andrey Turbanov 
 - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
   
   Co-authored-by: Andrey Turbanov 
 - TR29 final version
 - .md file update
 - Final 8/28
 - Draft 8/11
 - GenerateExtraProperties tool
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15728/files
  - new: https://git.openjdk.org/jdk/pull/15728/files/10527c07..31e397ce

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

  Stats: 41849 lines in 830 files changed: 7552 ins; 3478 del; 30819 mod
  Patch: https://git.openjdk.org/jdk/pull/15728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15728/head:pull/15728

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

From duke at openjdk.org  Mon Sep 18 18:54:07 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 18 Sep 2023 18:54:07 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v38]
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 incrementally with one additional commit since the last revision:

  Remove the unnecessary exception in single pivot partitioning fallback method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/e63a2aa0..7fc1afac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=36-37

  Stats: 25 lines in 3 files changed: 0 ins; 6 del; 19 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  Mon Sep 18 18:54:07 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 18 Sep 2023 18:54:07 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v36]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Sat, 16 Sep 2023 22:49:14 GMT, iaroslavski  wrote:

>> Hello Paul,
>> 
>> As suggested, the functional interfaces were moved next to the associated methods and also added a `@ForceInline` for `arraySort` in the latest commit.
>> 
>>> I recommend embedding the functional interfaces next to the associated methods, rather than as auxiliary classes, and also adding `@ForceInline` on `arraySort`.
>> 
>> Thanks,
>> Vamsi
>
> Hi @vamsi-parasa 
> 
> Why do we need ``if (indexPivot1 != indexPivot2) throw new IllegalArgumentException()``?
> If you implement logic correctly, you will never throw the exception.
> It is not business case, when exception makes sence.
> Therefore, I suggest removing this check.

Hello Vladimir (@iaroslavski),

Thanks for the suggestion. True, the exception check is not needed and removed in the latest commit pushed.

> Why do we need `if (indexPivot1 != indexPivot2) throw new IllegalArgumentException()`? If you implement logic correctly, you will never throw the exception. It is not business case, when exception makes sence. Therefore, I suggest removing this check.

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1724187218

From duke at openjdk.org  Mon Sep 18 18:54:47 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 18 Sep 2023 18:54:47 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v37]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 22:17:42 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:
> 
>   Move functional interfaces close to the associated methods

Hello Paul,

Could you please provide your approval if the Java side changes look good to you?
 
> I agree that is much cleaner, glad that worked out. That neatly covers multiple element types and Java-based insertion sort algorithms (although I don't know why we need two since mixed insertion effectively embeds the other but we don't need to address that here).
> 

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1724192098

From duke at openjdk.org  Mon Sep 18 18:59:55 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 18 Sep 2023 18:59:55 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v38]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 18:54:07 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:
> 
>   Remove the unnecessary exception in single pivot partitioning fallback method

make/modules/java.base/Lib.gmk line 1:

> 1: #

Hello Erik (@erikj79),

As per your suggestion, the library was renamed (to something more specific) as `libsmidsort`.  Could you please have a look at the build script and provide your approval if it looks good?

Thanks,
Vamsi

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1329157517

From djelinski at openjdk.org  Mon Sep 18 19:09:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Sep 2023 19:09:06 GMT
Subject: RFR: 8316433: net.dll should delay load winhttp.dll
Message-ID: <3JewS_yEE7WovrOepB3_NFB9nxjV3AqifVmwhB81hGk=.66298303-6c47-4413-a0b7-bf5425bdaa3a@github.com>

WinHTTP functions are only used when an application:
- uses DefaultProxySelector to resolve proxies, and
- is run with -Djava.net.useSystemProxies=true

In all other cases, loading winhttp.dll is a waste of resources.

Verified that:
- existing tier1 and tier2 tests still pass
- the same system proxies are returned with and without this patch
- WinHTTP is not loaded unless DefaultProxySelector is used

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

Commit messages:
 - Delayload winhttp

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

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

From rriggs at openjdk.org  Mon Sep 18 19:17:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Sep 2023 19:17:43 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: 
References: 
 
Message-ID: <4o-LifnC7St3sYg1LGniim_KB1_p8AGtx-znLcpbJKg=.17f86862-032c-487e-9f8c-174b094770a4@github.com>

On Mon, 18 Sep 2023 13:40:48 GMT, Chen Liang  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.
>
> src/java.base/share/classes/java/util/HexFormat.java line 422:
> 
>> 420:                         toHexDigits(out, bytes[fromIndex + i]);
>> 421:                     }
>> 422:                     out.append(suffix);
> 
> Maybe change this whole `else` block to
> 
>                     for (int i = 0; i < length; i++) {
>                         if (i > 0)
>                             out.append(delimiter);
>                         out.append(prefix);
>                         toHexDigits(out, bytes[fromIndex + i]);
>                         out.append(suffix);
>                     }
> 
> for clarity?

The original (and current) is coded to avoid a condition inside the loop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1329167394

From rriggs at openjdk.org  Mon Sep 18 19:17:46 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Sep 2023 19:17:46 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: 
References: 
Message-ID: 

On Fri, 15 Sep 2023 18:04:29 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.

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 101:

> 99:     public static short digitPair(int i) {
> 100:         return DIGITS[i & 0xff];
> 101:     }

DigitPair(i) appears to be unused and is redundant with DigitPair(i,boolean).

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 112:

> 110:         short v = DIGITS[i & 0xff];
> 111:         return ucase
> 112:                 ? (short) (v & ~((v & 0b0100_0000_0100_0000) >> 1)) // really: to uppper

Clever but perhaps ('a' - 'A') to make it clearer where the constant came from

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1329173096
PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1329067559

From duke at openjdk.org  Mon Sep 18 19:53:55 2023
From: duke at openjdk.org (iaroslavski)
Date: Mon, 18 Sep 2023 19:53:55 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v38]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 18:54:07 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:
> 
>   Remove the unnecessary exception in single pivot partitioning fallback method

Hi Vamsi,

1. I found your changes "the array" -> "an array" in DPQS class. Main Arrays class uses "the array", please look at
https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/Arrays.html#sort(int%5B%5D)
I think we must be consistent with this class. If you don't have objection, it would be nice to revert these changes.

2. You introduced benchmarking class test/micro/org/openjdk/bench/java/util/ArraysSort.java, that's great,
but there is the same class in PR https://raw.githubusercontent.com/openjdk/jdk/42e17e45b1adc4d77ba5549770ce591d96d4b1fe/test/micro/org/openjdk/bench/java/util/ArraysSort.java
which covers all types (not int/long/float/double only) and there are different data inputs (not random only).
Could you please switch to the more powerfull ArraysSort class?

Thank you,
Vladimir

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1724271996

From erikj at openjdk.org  Mon Sep 18 19:56:39 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 18 Sep 2023 19:56:39 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v2]
In-Reply-To: 
References: 
 
Message-ID: <3oiVmy0QNfQEwK5UwUwWBVCDxnBkpv0Llqd3Eo2b9ds=.acdd68c6-3e38-4fc6-855c-dc68023d4f5e@github.com>

On Mon, 18 Sep 2023 18:10:12 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
>> 
>> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
>> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
>> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
>> 
>> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
>> No new tests. Existing tier1-2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused define

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15789#pullrequestreview-1631856901

From erikj at openjdk.org  Mon Sep 18 19:59:41 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 18 Sep 2023 19:59:41 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 18:33:20 GMT, Naoto Sato  wrote:

>> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Fix GensrcRegex.gmk
>  - Merge branch 'master' into JDK-8296246-Unicode15.1
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - TR29 final version
>  - .md file update
>  - Final 8/28
>  - Draft 8/11
>  - GenerateExtraProperties tool
>  - initial commit

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15728#pullrequestreview-1631860355

From duke at openjdk.org  Mon Sep 18 20:11:56 2023
From: duke at openjdk.org (iaroslavski)
Date: Mon, 18 Sep 2023 20:11:56 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v38]
In-Reply-To: 
References: 
 
Message-ID: <4B1rAOrp9G91hu4y1g1krLUyCudusu60u4dP9ASkmp4=.92c602c1-67ab-4369-bb1d-86dcb8ebc876@github.com>

On Mon, 18 Sep 2023 18:54:07 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:
> 
>   Remove the unnecessary exception in single pivot partitioning fallback method

... more suggestions to have better code:

3. Rename introduced method arraySort() -> sort(), shorter and clear
4. The same for arrayPartition() -> partition(), shorter and clear
5. As I suggested before, please, remove line ``int[] pivotIndices;`` from the beginning at all and use the following:
int[] pivotIndices = partition(....) in both usages

Vansi, please, improve the code

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1724295231

From asemenyuk at openjdk.org  Mon Sep 18 20:15:48 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Sep 2023 20:15:48 GMT
Subject: Integrated: 8314909: tools/jpackage/windows/Win8282351Test.java fails
 with java.lang.AssertionError: Expected [0]. Actual [1618]:
In-Reply-To: 
References: 
Message-ID: 

On Fri, 15 Sep 2023 15:40:25 GMT, Alexey Semenyuk  wrote:

> Run jpackage jtreg tests on Windows sequentially. Asynch execution of `msiexec.exe` that unpacks msi files doesn't work well.

This pull request has now been integrated.

Changeset: 1b104b63
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/1b104b63a97ec947b34b85658153ab6c182cb56c
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8314909: tools/jpackage/windows/Win8282351Test.java fails with java.lang.AssertionError: Expected [0]. Actual [1618]:

Reviewed-by: almatvee

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

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

From asemenyuk at openjdk.org  Mon Sep 18 20:21:52 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Sep 2023 20:21:52 GMT
Subject: RFR: 8301247: JPackage app-image exe launches multiple exe's in
 JDK 17+ [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 15 Sep 2023 13:32:39 GMT, Alexey Semenyuk  wrote:

>> On Windows, restart app launcher in a way that when the parent app launcher process terminates, the child app launcher process is automatically terminated.
>
> Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Misplaced canRunLauncher() check.
>  - Added a test to cover the test case

Test output:


[23:18:54.466] Parsing [--jpt-run=Win8301247Test]...
[23:18:54.502] Win8301247Test.test -> [public void Win8301247Test.test() throws java.io.IOException,java.lang.InterruptedException]
[23:18:54.524] Create: Win8301247Test.test
[23:18:54.527] [ RUN      ] Win8301247Test.test
[23:18:54.804] TRACE: Bundler msi supported
[23:18:54.976] TRACE: Bundler exe supported
[23:18:55.007] TRACE: exec: Execute tool provider [javac -d .\test\jar-workdir C:\ade\mesos\work_dir\jib-master\install\2023-09-14-2207021.alexey.semenyuk.jdk10\src.full\open\test\jdk\tools\jpackage\apps\Hello.java](4)...
[23:18:56.167] TRACE: exec: Done. Exit code: 0
[23:18:56.168] TRACE: assertEquals(0): Check command tool provider [javac -d .\test\jar-workdir C:\ade\mesos\work_dir\jib-master\install\2023-09-14-2207021.alexey.semenyuk.jdk10\src.full\open\test\jdk\tools\jpackage\apps\Hello.java](4) exited with 0 code
[23:18:56.171] TRACE: exec: Execute tool provider [jar -c -f .\test\input\hello.jar -C .\test\jar-workdir .](7)...
[23:18:56.256] TRACE: exec: Done. Exit code: 0
[23:18:56.256] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test\input\hello.jar -C .\test\jar-workdir .](7) exited with 0 code
[23:18:56.264] TRACE: exec: Execute [windows-x64.jdk\jdk-22\bin\jpackage.exe --input .\test\input --dest .\test\output --name Win8301247Test --type app-image --main-jar hello.jar --main-class Hello --win-console --java-options -Djpackage.test.noexit=true -J-Djlink.debug=true --verbose](18); inherit I/O...
[23:18:56.647] Creating app package: Win8301247Test in C:\sb\prod\1694731099\testoutput\test-support\jtreg_open_test_jdk_tools_jpackage\scratch\1.\test\output
[23:19:03.132] Command [PID: -1]:
    jlink --output .\test\output\Win8301247Test\runtime --module-path windows-x64.jdk\\jdk-22\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.unsupported,jdk.jlink,java.smartcardio,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.transaction.xa,java.xml.crypto,java.logging,jdk.jfr,jdk.crypto.cryptoki,jdk.random,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.n
 aming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
[23:19:03.132] Output:
    WARNING: Using incubator modules: jdk.incubator.vector

[23:19:03.132] Returned: 0

[23:19:03.137] Using default package resource JavaApp.ico [icon] (add Win8301247Test.ico to the resource-dir to customize).
[23:19:03.169] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "c:\sb\prod\1694731099\testoutput\test-support\jtreg_open_test_jdk_tools_jpackage\tmp\jdk.jpackage11407434922052477626".
[23:19:03.172] Using default package resource WinLauncher.template [Template for creating executable properties file] (add Win8301247Test.properties to the resource-dir to customize).
[23:19:03.208] Succeeded in building Windows Application Image package
[23:19:03.319] TRACE: exec: Done. Exit code: 0
[23:19:03.320] TRACE: assertEquals(0): Check command [windows-x64.jdk\jdk-22\bin\jpackage.exe --input .\test\input --dest .\test\output --name Win8301247Test --type app-image --main-jar hello.jar --main-class Hello --win-console --java-options -Djpackage.test.noexit=true -J-Djlink.debug=true --verbose](18) exited with 0 code
[23:19:03.341] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
[23:19:03.344] TRACE: assertStringListEquals(1, .\test\output\Win8301247Test\app.jpackage.xml)
[23:19:03.352] TRACE: assertStringListEquals(): Check there are no files with [.package] name in the package
[23:19:03.353] TRACE: assertTrue(): Check [.\test\output\Win8301247Test\runtime] path exists
[23:19:03.353] TRACE: assertTrue(): Check [.\test\output\Win8301247Test\runtime] is a directory
[23:19:03.354] TRACE: assertTrue(): Check [.\test\output\Win8301247Test\Win8301247Test.exe] path exists
[23:19:03.354] TRACE: assertTrue(): Check [.\test\output\Win8301247Test\Win8301247Test.exe] is a file
[23:19:03.354] TRACE: assertTrue(): Check [.\test\output\Win8301247Test\Win8301247Test.exe] file is executable
[23:19:03.354] TRACE: assertTrue(): Check [.\test\output\Win8301247Test\app\Win8301247Test.cfg] path exists
[23:19:03.355] TRACE: assertTrue(): Check [.\test\output\Win8301247Test\app\Win8301247Test.cfg] is a file
[23:19:03.362] TRACE: Clearing PATH in environment
[23:19:03.363] TRACE: exec: Execute [C:\sb\prod\1694731099\testoutput\test-support\jtreg_open_test_jdk_tools_jpackage\scratch\1.\test\output\Win8301247Test\Win8301247Test.exe](1); save output; in directory [.\test]...
[23:19:13.361] TRACE: exec: Execute [wmic process where (name = "Win8301247Test.exe" ) get ProcessID,ParentProcessID](9); save output...
ParentProcessId  ProcessId  

41052            31224      

31224            11344      



[23:19:13.553] TRACE: exec: Done. Exit code: 0
[23:19:13.553] TRACE: assertEquals(0): Check command [wmic process where (name = "Win8301247Test.exe" ) get ProcessID,ParentProcessID](9) exited with 0 code
[23:19:13.557] TRACE: assertEquals(2): Check [2] app launcher processes found running
[23:19:13.557] TRACE: exec: Execute [taskkill /F /PID 31224](4); inherit I/O...
SUCCESS: The process with PID 31224 has been terminated.
[23:19:13.639] TRACE: exec: Done. Exit code: 1
[23:19:13.640] TRACE: exec: Done. Exit code: 0
[23:19:13.640] TRACE: assertEquals(0): Check command [taskkill /F /PID 31224](4) exited with 0 code
[23:19:18.649] TRACE: exec: Execute [wmic process where (name = "Win8301247Test.exe" ) get ProcessID,ParentProcessID](9); save output...
No Instance(s) Available.





[23:19:18.749] TRACE: exec: Done. Exit code: 0
[23:19:18.750] TRACE: assertEquals(0): Check command [wmic process where (name = "Win8301247Test.exe" ) get ProcessID,ParentProcessID](9) exited with 0 code
[23:19:18.750] TRACE: assertEquals(No Instance(s) Available.): Check no app launcher processes found running
[23:19:18.751] TRACE: Deleting [.\test] directory recursively
[23:19:18.862] [       OK ] Win8301247Test.test; checks=17
[23:19:18.863] [==========] 1 tests ran
[23:19:18.863] [  PASSED  ] 1 test

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

PR Comment: https://git.openjdk.org/jdk/pull/15690#issuecomment-1724307706

From asemenyuk at openjdk.org  Mon Sep 18 20:21:54 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Sep 2023 20:21:54 GMT
Subject: Integrated: 8301247: JPackage app-image exe launches multiple exe's in
 JDK 17+
In-Reply-To: 
References: 
Message-ID: 

On Tue, 12 Sep 2023 19:47:19 GMT, Alexey Semenyuk  wrote:

> On Windows, restart app launcher in a way that when the parent app launcher process terminates, the child app launcher process is automatically terminated.

This pull request has now been integrated.

Changeset: dcea9bf0
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/dcea9bf087c87548d9caa899c52e95d17478da22
Stats:     667 lines in 6 files changed: 434 ins; 217 del; 16 mod

8301247: JPackage app-image exe launches multiple exe's in JDK 17+

Reviewed-by: almatvee

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

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

From smarks at openjdk.org  Mon Sep 18 21:28:02 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 18 Sep 2023 21:28:02 GMT
Subject: RFR: 8314896: additional clarifications to reversed() default methods'
 implementation requirements
Message-ID: 

Wording changes to make clear that the scenarios described are merely examples and are not normative requirements.

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

Commit messages:
 - Update wording for {Deque,List,SortedMap,SortedSet}.reversed implSpecs.

Changes: https://git.openjdk.org/jdk/pull/15799/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15799&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314896
  Stats: 12 lines in 4 files changed: 0 ins; 0 del; 12 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 jlu at openjdk.org  Mon Sep 18 22:11:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Sep 2023 22:11:52 GMT
Subject: Integrated: 8313813: Field
 sun.util.calendar.CalendarDate#forceStandardTime is never set
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 17:52:13 GMT, Justin Lu  wrote:

> Please review this PR which is a continuation of [JDK-6453901](https://bugs.openjdk.org/browse/JDK-6453901) to remove unused code from the _sun.util.Calendar_ classes.
> 
> `forceStandardTime` is always false.
> 
> In addition, `locale` is never by used by _CalendarDate_ or any inheritors and can be removed.
> 
> As a result, _ImmutableGregorianDate_ no longer needs to override the _setLocale_ method and throw UnsupportedOperationException.

This pull request has now been integrated.

Changeset: 373e37bf
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/373e37bf13df654ba40c0bd9fcf345215be4eafb
Stats:     49 lines in 3 files changed: 1 ins; 39 del; 9 mod

8313813: Field sun.util.calendar.CalendarDate#forceStandardTime is never set

Reviewed-by: aturbanov, naoto

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

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

From jlu at openjdk.org  Mon Sep 18 22:48:53 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Sep 2023 22:48:53 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing should
 be restricted
Message-ID: 

Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations.

As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).


This system has the following structure,

`CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
(`Gregorian, JulianCalendar, LocalGregorianCalendar`)

`CalendarDate` extended by `BaseCalendar.Date` extended by 
(`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)

Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.

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

Commit messages:
 - private constructor in CalendarUtils
 - Make utility class 'CalendarUtils' final
 - Copyright years
 - Seal the rest of the 'CalendarSystem'
 - Clarify public for LCG.date, when other BaseCalendar.date inheritors are default
 - Seal BaseCalendar and make inheritors final
 - Seal BaseCalendar.Date and make inheritors final

Changes: https://git.openjdk.org/jdk/pull/15803/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15803&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316435
  Stats: 40 lines in 9 files changed: 7 ins; 0 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/15803.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15803/head:pull/15803

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

From mchung at openjdk.org  Mon Sep 18 23:07:01 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 18 Sep 2023 23:07:01 GMT
Subject: RFR: 8316456: StackWalker may skip Continuation::yield0 frame
 mistakenly
Message-ID: 

`JVM_MoreStackWalk` has a bug that always assumes that the Java frame
stream is currently at the frame decoded in the last patch and so always
advances to the next frame before filling in the new batch of stack frame.
However `JVM_MoreStackWalk` may return 0.  The library will set 
the continuation to its parent. It then call `JVM_MoreStackWalk` to continue
the stack walking but the last decoded frame has already been advanced.
The Java frame stream is already at the top frame of the parent continuation. .
The current implementation skips "Continuation::yield0" mistakenly.  This
only happens with `-XX:+ShowHiddenFrames` or `StackWalker.Option.SHOW_HIDDEN_FRAMES`.

The fix is to pass the number of frames decoded in the last batch to `JVM_MoreStackWalk`
so that the VM will determine if the current frame should be skipped or not.

`test/jdk/jdk/internal/vm/Continuation/Scoped.java` test now correctly checks
the expected result where "yield0" exists between "enter" and "run" frames.

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

Commit messages:
 - 8316456: StackWalker may skip Continuation::yield0 frame mistakenly

Changes: https://git.openjdk.org/jdk/pull/15804/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15804&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316456
  Stats: 128 lines in 7 files changed: 36 ins; 11 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/15804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15804/head:pull/15804

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

From naoto at openjdk.org  Tue Sep 19 01:10:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 01:10:09 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing
Message-ID: 

Fixed the failing (well, false-positive) test case. Made the following changes to the test:

- Corrected the path to the mapping files directory
- Made sure to fail if the directory path is incorrect
- Took care of `GB18030` alias, which is dynamically derived at runtime
- Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
- Excluded other failing tests for IBM charsets that do not have map files.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/15807/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15807&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310631
  Stats: 20 lines in 2 files changed: 14 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15807/head:pull/15807

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

From duke at openjdk.org  Tue Sep 19 01:38:50 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 01:38:50 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: <4o-LifnC7St3sYg1LGniim_KB1_p8AGtx-znLcpbJKg=.17f86862-032c-487e-9f8c-174b094770a4@github.com>
References: 
 
 <4o-LifnC7St3sYg1LGniim_KB1_p8AGtx-znLcpbJKg=.17f86862-032c-487e-9f8c-174b094770a4@github.com>
Message-ID: 

On Mon, 18 Sep 2023 19:08:14 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/java/util/HexFormat.java line 422:
>> 
>>> 420:                         toHexDigits(out, bytes[fromIndex + i]);
>>> 421:                     }
>>> 422:                     out.append(suffix);
>> 
>> Maybe change this whole `else` block to
>> 
>>                     for (int i = 0; i < length; i++) {
>>                         if (i > 0)
>>                             out.append(delimiter);
>>                         out.append(prefix);
>>                         toHexDigits(out, bytes[fromIndex + i]);
>>                         out.append(suffix);
>>                     }
>> 
>> for clarity?
>
> The original (and current) is coded to avoid a condition inside the loop.

I also think that the way of writing for_0 combined with if > 0 is easier to understand, The operation overhead of if > 0 is very small, and it will not affect performance when used in a loop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1329453524

From duke at openjdk.org  Tue Sep 19 01:50:20 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 01:50:20 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v2]
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:

  remove digitPair(int) and fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15768/files
  - new: https://git.openjdk.org/jdk/pull/15768/files/530ca013..807cd956

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

  Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 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 duke at openjdk.org  Tue Sep 19 01:57:44 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 19 Sep 2023 01:57:44 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v39]
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 incrementally with two additional commits since the last revision:

 - Update DualPivotQuicksort.java
 - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/7fc1afac..3e0b8cfc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=37-38

  Stats: 47 lines in 2 files changed: 0 ins; 8 del; 39 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 jwaters at openjdk.org  Tue Sep 19 02:10:39 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 19 Sep 2023 02:10:39 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 18:10:12 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
>> 
>> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
>> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
>> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
>> 
>> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
>> No new tests. Existing tier1-2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused define

Seems like JDK-8288293 no longer has to rely on delay load failure hooks to bypass gcc's lack of Structured Exception Handling :)

Is the ole32.lib dependency related to CoTaskMemFree?

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

PR Comment: https://git.openjdk.org/jdk/pull/15789#issuecomment-1724726095

From duke at openjdk.org  Tue Sep 19 02:17:06 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 19 Sep 2023 02:17:06 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v38]
In-Reply-To: <4B1rAOrp9G91hu4y1g1krLUyCudusu60u4dP9ASkmp4=.92c602c1-67ab-4369-bb1d-86dcb8ebc876@github.com>
References: 
 
 <4B1rAOrp9G91hu4y1g1krLUyCudusu60u4dP9ASkmp4=.92c602c1-67ab-4369-bb1d-86dcb8ebc876@github.com>
Message-ID: 

On Mon, 18 Sep 2023 20:08:31 GMT, iaroslavski  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the unnecessary exception in single pivot partitioning fallback method
>
> ... more suggestions to have better code:
> 
> 3. Rename introduced method arraySort() -> sort(), shorter and clear
> 4. The same for arrayPartition() -> partition(), shorter and clear
> 5. As I suggested before, please, remove line ``int[] pivotIndices;`` from the beginning at all and use the following:
> int[] pivotIndices = partition(....) in both usages
> 
> Vansi, please, improve the code

Hello Vladimir (@iaroslavski )

Thank you for the suggestions!  
Please see all the changes you suggested below implemented in the latest commit pushed. 

> 1. I found your changes "the array" -> "an array" in DPQS class
> 3. Rename introduced method arraySort() -> sort(), shorter and clear
> 4. The same for arrayPartition() -> partition(), shorter and clear
> 5. As I suggested before, please, remove line `int[] pivotIndices;` from the beginning at all and use the following:
>    int[] pivotIndices = partition(....) in both usages

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1724730003

From duke at openjdk.org  Tue Sep 19 02:22:54 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 19 Sep 2023 02:22:54 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v39]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 01:57:44 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 two additional commits since the last revision:
> 
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments

Hello Vladimir (@iaroslavski ),

Could you please file a separate PR for integrating the `ArraysSort.java` JMH benchmark? 

> 2. You introduced benchmarking class test/micro/org/openjdk/bench/java/util/ArraysSort.java, that's great,
>    but there is the same class in PR https://raw.githubusercontent.com/openjdk/jdk/42e17e45b1adc4d77ba5549770ce591d96d4b1fe/test/micro/org/openjdk/bench/java/util/ArraysSort.java
>    which covers all types (not int/long/float/double only) and there are different data inputs (not random only).
>    Could you please switch to the more powerfull ArraysSort class?

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1724733679

From duke at openjdk.org  Tue Sep 19 05:00:40 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 05:00:40 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex
In-Reply-To: 
References: 
 <8_s_QemlqUYrlWpyP1gu8s36PMChNdTfgbxHDHb4IlA=.99958ce3-948b-4aae-89d9-a14fd1eb2393@github.com>
 
Message-ID: <-dCx2VmFaiP6Q8G07zFEx8M-3SjzOogq3K2fsTEKegE=.2f069665-705d-44f4-a62c-51cd762b9d6c@github.com>

On Mon, 18 Sep 2023 17:18:29 GMT, Roger Riggs  wrote:

> > HexDecimal#DIGITS is a table with a size of 512 bytes. I think that in such a table, when it needs to be used continuously, it is worthwhile to perform table lookup operations.
> 
> HexFormat was designed for presenting bytes to humans, typical line lengths for the useful output are 80-130 characters, so input sizes of 40-65 bytes, probably less when other interpretations (such as latin1 or ascii) are appended. And the output is not typically performance sensitive. Please keep the code small and easy to maintain.

If the input is byte[], there may be performance requirements. Other scenarios, such as toHexDigits, may not be performance sensitive. For code consistency, HexDigits.digitPair should be used by all methods of HexFormat.

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

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1724831658

From alanb at openjdk.org  Tue Sep 19 06:43:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 06:43:40 GMT
Subject: RFR: 8316433: net.dll should delay load winhttp.dll
In-Reply-To: <3JewS_yEE7WovrOepB3_NFB9nxjV3AqifVmwhB81hGk=.66298303-6c47-4413-a0b7-bf5425bdaa3a@github.com>
References: <3JewS_yEE7WovrOepB3_NFB9nxjV3AqifVmwhB81hGk=.66298303-6c47-4413-a0b7-bf5425bdaa3a@github.com>
Message-ID: 

On Mon, 18 Sep 2023 17:30:25 GMT, Daniel Jeli?ski  wrote:

> WinHTTP functions are only used when an application:
> - uses DefaultProxySelector to resolve proxies, and
> - is run with -Djava.net.useSystemProxies=true
> 
> In all other cases, loading winhttp.dll is a waste of resources.
> 
> Verified that:
> - existing tier1 and tier2 tests still pass
> - the same system proxies are returned with and without this patch
> - WinHTTP is not loaded unless DefaultProxySelector is used

test/jdk/java/net/ProxySelector/SystemProxies.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 6912868 8170868 8316433

You may have used this test to ensure that the change didn't cause a regression but I don't think it should be added the `@bug` list for the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15793#discussion_r1329642122

From djelinski at openjdk.org  Tue Sep 19 07:01:40 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Sep 2023 07:01:40 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 18:10:12 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
>> 
>> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
>> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
>> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
>> 
>> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
>> No new tests. Existing tier1-2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused define

Yes, ole32.lib was needed for CoTaskMemFree. Without it the library wouldn't link.

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

PR Comment: https://git.openjdk.org/jdk/pull/15789#issuecomment-1724935308

From djelinski at openjdk.org  Tue Sep 19 07:02:32 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Sep 2023 07:02:32 GMT
Subject: RFR: 8316433: net.dll should delay load winhttp.dll [v2]
In-Reply-To: <3JewS_yEE7WovrOepB3_NFB9nxjV3AqifVmwhB81hGk=.66298303-6c47-4413-a0b7-bf5425bdaa3a@github.com>
References: <3JewS_yEE7WovrOepB3_NFB9nxjV3AqifVmwhB81hGk=.66298303-6c47-4413-a0b7-bf5425bdaa3a@github.com>
Message-ID: 

> WinHTTP functions are only used when an application:
> - uses DefaultProxySelector to resolve proxies, and
> - is run with -Djava.net.useSystemProxies=true
> 
> In all other cases, loading winhttp.dll is a waste of resources.
> 
> Verified that:
> - existing tier1 and tier2 tests still pass
> - the same system proxies are returned with and without this patch
> - WinHTTP is not loaded unless DefaultProxySelector is used

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Revert test changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15793/files
  - new: https://git.openjdk.org/jdk/pull/15793/files/16e43b79..6a382ca3

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

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

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

From djelinski at openjdk.org  Tue Sep 19 07:02:34 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Sep 2023 07:02:34 GMT
Subject: RFR: 8316433: net.dll should delay load winhttp.dll [v2]
In-Reply-To: 
References: <3JewS_yEE7WovrOepB3_NFB9nxjV3AqifVmwhB81hGk=.66298303-6c47-4413-a0b7-bf5425bdaa3a@github.com>
 
Message-ID: 

On Tue, 19 Sep 2023 06:41:11 GMT, Alan Bateman  wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert test changes
>
> test/jdk/java/net/ProxySelector/SystemProxies.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 6912868 8170868 8316433
> 
> You may have used this test to ensure that the change didn't cause a regression but I don't think it should be added the `@bug` list for the test.

Thanks, I wasn't sure about that. I'll revert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15793#discussion_r1329655051

From pminborg at openjdk.org  Tue Sep 19 07:10:06 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 19 Sep 2023 07:10:06 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased
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.

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

Commit messages:
 - Merge pull request #4 from cl4es/HashMapViews
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316493
  Stats: 276 lines in 9 files changed: 92 ins; 107 del; 77 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  Tue Sep 19 07:10:07 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 19 Sep 2023 07:10:07 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased
In-Reply-To: 
References: 
Message-ID: <52aVFfyLhJCKzAhk8W2O3lXLFZkia7ThLp3YwYOLVjA=.9d30bf96-cc49-421e-a29c-6f6190b0d411@github.com>

On Thu, 7 Sep 2023 11:13:44 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.

@cl4es ran some benchmarks:


Name                      (size) Cnt  Base   Error   Test   Error   Unit   Diff%
HashMapViews.entrySetSize      1   5 1,085 ? 0,118  1,003 ? 0,053  ns/op    7,6% (p = 0,002*)
  :gc.alloc.rate             N/A   5 0,013 ? 0,000  0,013 ? 0,000 MB/sec   -0,1% (p = 0,639 )
  :gc.alloc.rate.norm        N/A   5 0,000 ? 0,000  0,000 ? 0,000   B/op   -7,7% (p = 0,003*)
  :gc.count                  N/A   5 0,000          0,000         counts
HashMapViews.entrySetSize   1000   5 1,001 ? 0,026  1,033 ? 0,170  ns/op   -3,3% (p = 0,173 )
  :gc.alloc.rate             N/A   5 0,013 ? 0,000  0,013 ? 0,000 MB/sec    0,6% (p = 0,012 )
  :gc.alloc.rate.norm        N/A   5 0,000 ? 0,000  0,000 ? 0,000   B/op    3,9% (p = 0,124 )
  :gc.count                  N/A   5 0,000          0,000         counts
HashMapViews.keySetSize        1   5 1,051 ? 0,017  0,706 ? 0,008  ns/op   32,8% (p = 0,000*)
  :gc.alloc.rate             N/A   5 0,013 ? 0,000  0,013 ? 0,000 MB/sec    0,0% (p = 0,947 )
  :gc.alloc.rate.norm        N/A   5 0,000 ? 0,000  0,000 ? 0,000   B/op  -32,8% (p = 0,000*)
  :gc.count                  N/A   5 0,000          0,000         counts
HashMapViews.keySetSize     1000   5 1,078 ? 0,013  0,705 ? 0,006  ns/op   34,6% (p = 0,000*)
  :gc.alloc.rate             N/A   5 0,013 ? 0,000  0,013 ? 0,000 MB/sec   -0,1% (p = 0,756 )
  :gc.alloc.rate.norm        N/A   5 0,000 ? 0,000  0,000 ? 0,000   B/op  -34,7% (p = 0,000*)
  :gc.count                  N/A   5 0,000          0,000         counts
HashMapViews.valuesSize        1   5 0,998 ? 0,033  0,718 ? 0,062  ns/op   28,1% (p = 0,000*)
  :gc.alloc.rate             N/A   5 0,013 ? 0,000  0,013 ? 0,000 MB/sec    0,7% (p = 0,055 )
  :gc.alloc.rate.norm        N/A   5 0,000 ? 0,000  0,000 ? 0,000   B/op  -27,6% (p = 0,000*)
  :gc.count                  N/A   5 0,000          0,000         counts
HashMapViews.valuesSize     1000   5 1,043 ? 0,062  0,705 ? 0,011  ns/op   32,4% (p = 0,000*)
  :gc.alloc.rate             N/A   5 0,013 ? 0,000  0,013 ? 0,000 MB/sec   -0,3% (p = 0,405 )
  :gc.alloc.rate.norm        N/A   5 0,000 ? 0,000  0,000 ? 0,000   B/op  -32,6% (p = 0,000*)
  :gc.count                  N/A   5 0,000          0,000         counts
  * = significant

Invariant parameters used by above microbenchmarks:
mapType:   HashMap

src/java.base/share/classes/java/util/AbstractMap.java line 323:

> 321:         return new AbstractSet<>() {
> 322:             public Iterator iterator() {
> 323:                 return new Iterator<>() {

There is another PR that proposes to refactor these anonymous classes: https://github.com/openjdk/jdk/pull/15615/files

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

PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-1710165103
PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1329664799

From redestad at openjdk.org  Tue Sep 19 07:10:07 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 19 Sep 2023 07:10:07 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased
In-Reply-To: 
References: 
Message-ID: <534xb0ZBFEjwE9X4HFIYhx3SLHDtT3Z7qiSbS6J__j4=.6ca021f3-2179-4ce9-9e94-3fdeb623d6af@github.com>

On Thu, 7 Sep 2023 11:13:44 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.

The microbenchmark is deliberately minimalist and mainly verifies that the JIT _can_ eliminate allocation of the `keySet` and `values` and is as such a good starting point for further analysis. Worth noting also that eliminating these two transient fields would save 8-16 bytes from every `HashMap`, `LinkedHashMap`, `Map.of(..)` et.c.

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

PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-1710352704

From duke at openjdk.org  Tue Sep 19 08:49:21 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 08:49:21 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v3]
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 two additional commits since the last revision:

 - update comments
 - update comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15768/files
  - new: https://git.openjdk.org/jdk/pull/15768/files/807cd956..1724e667

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 liach at openjdk.org  Tue Sep 19 08:49:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Sep 2023 08:49:44 GMT
Subject: RFR: 8315850: Improve AbstractMap anonymous Iterator classes [v3]
In-Reply-To: 
References: 
 
Message-ID: <6vsZDlrQZKetwFv40X-ajTxCnpSUgt_vOgz-w23ieLY=.f13ce100-53f5-4408-bded-0725dc3cb89f@github.com>

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 liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15615#pullrequestreview-1632740299

From liach at openjdk.org  Tue Sep 19 08:55:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Sep 2023 08:55:40 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased
In-Reply-To: 
References: 
Message-ID: 

On Thu, 7 Sep 2023 11:13:44 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.

Good starting point to make even more maps, like regular enum map, value-based.

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/15614#pullrequestreview-1632752346

From duke at openjdk.org  Tue Sep 19 09:03:35 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 09:03:35 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v4]
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:

  "-" -> "& ~"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15768/files
  - new: https://git.openjdk.org/jdk/pull/15768/files/1724e667..b68defa2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 liach at openjdk.org  Tue Sep 19 09:28:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Sep 2023 09:28:41 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 09:03:35 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:
> 
>   "-" -> "& ~"

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 103:

> 101:         short v = DIGITS[i & 0xff];
> 102:         return ucase
> 103:                 ? (short) (v - ((v & 0b0100_0000_0100_0000) >> 1)) // really: v - ((v >= 'a' && v <= 'f') ? 32 : 0)

I think this logic is somewhat complicated that explaining directly is better:
`0b0100_0000_0100_0000` is a selector that selects letters (1 << 6), uppercase or not, and shifting it right by 1 bit incidentally becomes a bit offset between cases (1 << 5).

I think you can keep the original `& ~` which is clearer (as `-` will not work had the differences not be aligned bit-wise). But you should explain what `>> 1` does which is a major hurdle to understanding this function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1329835145

From redestad at openjdk.org  Tue Sep 19 09:37:43 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 19 Sep 2023 09:37:43 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <5c8dicpw0dRMJSQMCFbQAco6MkjnYsmqBmNr0Bo4LXc=.edc2e1ec-01bb-4a46-902a-fcde23b8a323@github.com>

On Tue, 19 Sep 2023 09:25:36 GMT, Chen Liang  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   "-" -> "& ~"
>
> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 103:
> 
>> 101:         short v = DIGITS[i & 0xff];
>> 102:         return ucase
>> 103:                 ? (short) (v - ((v & 0b0100_0000_0100_0000) >> 1)) // really: v - ((v >= 'a' && v <= 'f') ? 32 : 0)
> 
> I think this logic is somewhat complicated that explaining directly is better:
> `0b0100_0000_0100_0000` is a selector that selects letters (1 << 6), uppercase or not, and shifting it right by 1 bit incidentally becomes a bit offset between cases (1 << 5).
> 
> I think you can keep the original `& ~` which is clearer (as `-` will not work had the differences not be aligned bit-wise). But you should explain what `>> 1` does which is a major hurdle to understanding this function.

If we changed DIGITS to be encoded with the uppercase digits then the expression could be simplified to
```return ucase ? v : (short) (v | 0b0010_0000_0010_0000); // or 0x2020```

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1329846187

From prappo at openjdk.org  Tue Sep 19 09:49:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 19 Sep 2023 09:49:53 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v7]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: 

> 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/1c86621d...77bfab34

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/6fa3f694..77bfab34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=05-06

  Stats: 105957 lines in 3261 files changed: 46415 ins; 17757 del; 41785 mod
  Patch: https://git.openjdk.org/jdk/pull/14630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14630/head:pull/14630

PR: https://git.openjdk.org/jdk/pull/14630

From cstein at openjdk.org  Tue Sep 19 10:02:40 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 19 Sep 2023 10:02:40 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 15 Aug 2023 08:07:09 GMT, Christian Stein  wrote:

>> test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2020, 2021, 2023, Oracle and/or its affiliates. All rights reserved.
>> 
>> Should it just modify the second year, here is `2021`, to `2023`?
>
> Yes, good catch! I added two more occurances to my second review.

The line must only two years. Like so:

` * Copyright (c) 2020, 2023, Oracle and/or its affiliates. All rights reserved.`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15131#discussion_r1329878287

From liach at openjdk.org  Tue Sep 19 10:10:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Sep 2023 10:10:44 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 7 Sep 2023 07:15:06 GMT, Qing Xiao  wrote:

>> Modified all tests under lib-test/jdk to use JUnit
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change test static method to instance method

test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java line 214:

> 212:     }
> 213: 
> 214:     // PrimitiveFormatters

This comment is now useless.
Suggestion:

test/lib-test/jdk/test/lib/hexdump/ObjectStreamPrinterTest.java line 90:

> 88:     }
> 89: 
> 90:     // SingleObjects

Suggestion:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15131#discussion_r1329887061
PR Review Comment: https://git.openjdk.org/jdk/pull/15131#discussion_r1329888251

From cstein at openjdk.org  Tue Sep 19 10:17:41 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 19 Sep 2023 10:17:41 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests [v3]
In-Reply-To: 
References: 
 
Message-ID: <1wKJmGeHj0LqbUBEARWbW8s2yOe0nwPweLFzUFOyU6o=.e888b5f0-adfa-4639-8511-3bb22c2d5640@github.com>

On Thu, 7 Sep 2023 07:15:06 GMT, Qing Xiao  wrote:

>> Modified all tests under lib-test/jdk to use JUnit
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change test static method to instance method

test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2021, 2023, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2020, 2023, Oracle and/or its affiliates. All rights reserved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15131#discussion_r1329896061

From duke at openjdk.org  Tue Sep 19 10:29:43 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 10:29:43 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v4]
In-Reply-To: <5c8dicpw0dRMJSQMCFbQAco6MkjnYsmqBmNr0Bo4LXc=.edc2e1ec-01bb-4a46-902a-fcde23b8a323@github.com>
References: 
 
 
 <5c8dicpw0dRMJSQMCFbQAco6MkjnYsmqBmNr0Bo4LXc=.edc2e1ec-01bb-4a46-902a-fcde23b8a323@github.com>
Message-ID: 

On Tue, 19 Sep 2023 09:34:56 GMT, Claes Redestad  wrote:

>> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 103:
>> 
>>> 101:         short v = DIGITS[i & 0xff];
>>> 102:         return ucase
>>> 103:                 ? (short) (v - ((v & 0b0100_0000_0100_0000) >> 1)) // really: v - ((v >= 'a' && v <= 'f') ? 32 : 0)
>> 
>> I think this logic is somewhat complicated that explaining directly is better:
>> `0b0100_0000_0100_0000` is a selector that selects letters (1 << 6), uppercase or not, and shifting it right by 1 bit incidentally becomes a bit offset between cases (1 << 5).
>> 
>> I think you can keep the original `& ~` which is clearer (as `-` will not work had the differences not be aligned bit-wise). But you should explain what `>> 1` does which is a major hurdle to understanding this function.
>
> If we changed DIGITS to be encoded with the uppercase digits then the expression could be simplified to
> ```return ucase ? v : (short) (v | 0b0010_0000_0010_0000); // or 0x2020```

Some performance-focused scenarios, such as UUID.toString, use lowercase, so I think DIGITS should be lowercase.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1329908384

From alanb at openjdk.org  Tue Sep 19 10:35:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 10:35:33 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v4]
In-Reply-To: 
References: 
Message-ID: <9VfrX05npD49cxC_Oz-roD8GOFrGOxx_8gUNE6LiC5I=.c1088d6e-7ba1-432a-a0a6-82c995fd6e0d@github.com>

> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue with debuggers because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
> 
> The change is straight-forward with additional state for timed-parking/parked/pinned. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge
 - Reorder getState tests, use assertEquals and misc. cleanup
 - Merge
 - Merge
 - Revert back to explicit TIMED_xxx states
 - Merge
 - Merge
 - Merge
 - Remove unecessary RF from test
 - Merge
 - ... and 7 more: https://git.openjdk.org/jdk/compare/5a10d32c...ac8da3e5

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14978/files
  - new: https://git.openjdk.org/jdk/pull/14978/files/70b7766d..ac8da3e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14978&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14978&range=02-03

  Stats: 43518 lines in 857 files changed: 8140 ins; 4569 del; 30809 mod
  Patch: https://git.openjdk.org/jdk/pull/14978.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14978/head:pull/14978

PR: https://git.openjdk.org/jdk/pull/14978

From alanb at openjdk.org  Tue Sep 19 10:37:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 10:37:41 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com>
References: 
 
 
 
 
 <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com>
Message-ID: 

On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing  wrote:

>>> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops
>> 
>> Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops.
>
>> > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops
>> 
>> Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops.
> 
> I think it's useful if trying to trace the calls (i.e. set to 0ms).  Apparently the security manager was being used for that by some.

> @tprinzing 
> Your change (at version [9fa2745](https://github.com/openjdk/jdk/commit/9fa2745960aea0bc45642081bac89fb5ef65809e)) is now ready to be sponsored by a Committer.

@tprinzing I don't mind sponsoring but I think it would help if you could sync up the branch and provide a summary on the testing was done.  The jdk_net and jdk_nio test groups are in tier2. The jdk_jfr test group is in tier3.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1725248917

From duke at openjdk.org  Tue Sep 19 10:38:27 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 10:38:27 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v5]
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:

  update comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15768/files
  - new: https://git.openjdk.org/jdk/pull/15768/files/b68defa2..6f53d988

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=03-04

  Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 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 duke at openjdk.org  Tue Sep 19 10:41:51 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 10:41:51 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v6]
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 two additional commits since the last revision:

 - update comments
 - update comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15768/files
  - new: https://git.openjdk.org/jdk/pull/15768/files/6f53d988..ee78697d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 duke at openjdk.org  Tue Sep 19 10:44:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 10:44:41 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v4]
In-Reply-To: 
References: 
 
 
 <5c8dicpw0dRMJSQMCFbQAco6MkjnYsmqBmNr0Bo4LXc=.edc2e1ec-01bb-4a46-902a-fcde23b8a323@github.com>
 
Message-ID: <4ITuNVqnoaJ6gpyzMD9-qjLoBBnDNrIQ17MMOaACB0U=.e165ac75-0116-42f1-9b22-6ec5bc94f54f@github.com>

On Tue, 19 Sep 2023 10:26:50 GMT, ???  wrote:

>> If we changed DIGITS to be encoded with the uppercase digits then the expression could be simplified to
>> ```return ucase ? v : (short) (v | 0b0010_0000_0010_0000); // or 0x2020```
>
> Some performance-focused scenarios, such as UUID.toString, use lowercase, so I think DIGITS should be lowercase.

> I think this logic is somewhat complicated that explaining directly is better: `0b0100_0000_0100_0000` is a selector that selects letters (1 << 6), uppercase or not, and shifting it right by 1 bit incidentally becomes a bit offset between cases (1 << 5).
> 
> I think you can keep the original `& ~` which is clearer (as `-` will not work had the differences not be aligned bit-wise). But you should explain what `>> 1` does which is a major hurdle to understanding this function.

I have added your explanation and it is very well written.

I changed it to "-" because there is one less operation and it is easier to explain.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1329923039

From rpressler at openjdk.org  Tue Sep 19 10:49:42 2023
From: rpressler at openjdk.org (Ron Pressler)
Date: Tue, 19 Sep 2023 10:49:42 GMT
Subject: RFR: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked [v4]
In-Reply-To: <9VfrX05npD49cxC_Oz-roD8GOFrGOxx_8gUNE6LiC5I=.c1088d6e-7ba1-432a-a0a6-82c995fd6e0d@github.com>
References: 
 <9VfrX05npD49cxC_Oz-roD8GOFrGOxx_8gUNE6LiC5I=.c1088d6e-7ba1-432a-a0a6-82c995fd6e0d@github.com>
Message-ID: <2V3irr9WfRrEh_zZECbAw6uLqLHyJ0yyeBy_Ee_akgE=.ef512781-908b-4c03-9122-204027c4de44@github.com>

On Tue, 19 Sep 2023 10:35:33 GMT, Alan Bateman  wrote:

>> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue with debuggers because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
>> 
>> The change is straight-forward with additional state for timed-parking/parked/pinned. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge
>  - Reorder getState tests, use assertEquals and misc. cleanup
>  - Merge
>  - Merge
>  - Revert back to explicit TIMED_xxx states
>  - Merge
>  - Merge
>  - Merge
>  - Remove unecessary RF from test
>  - Merge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/e8d8f7ea...ac8da3e5

Marked as reviewed by rpressler (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14978#pullrequestreview-1632962730

From alanb at openjdk.org  Tue Sep 19 11:00:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 11:00:55 GMT
Subject: Integrated: 8312498: Thread::getState and JVM TI GetThreadState should
 return TIMED_WAITING virtual thread is timed parked
In-Reply-To: 
References: 
Message-ID: 

On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman  wrote:

> Thread::getState is an API for monitoring and management purposes to report the thread state. If a virtual thread is parked with LockSupport.parkNanos, its state is reported as  WAITING when it should be TIMED_WAITING. JVM TI GetThreadState has the same issue in that it returns JVMTI_THREAD_STATE_WAITING_INDEFINITELY instead of the JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT bit set. Not a very visible issue with debuggers because JDWP maps both states to "WAIT" but it may be noticed by tools using other JVM TI agents.
> 
> The change is straight-forward with additional state for timed-parking/parked/pinned. The existing virtual/ThreadAPI.java test is expanded to this scenario. A new test is added for JVM TI GetThreadState to test waiting/timed-waited cases (including pinned) as test coverage seems patchy here.

This pull request has now been integrated.

Changeset: 4461eeb3
Author:    Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/4461eeb31d5ccc89e304329a7dccb9cb130713fc
Stats:     873 lines in 10 files changed: 697 ins; 57 del; 119 mod

8312498: Thread::getState and JVM TI GetThreadState should return TIMED_WAITING virtual thread is timed parked

Reviewed-by: sspitsyn, rpressler

-------------

PR: https://git.openjdk.org/jdk/pull/14978

From duke at openjdk.org  Tue Sep 19 11:59:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 11:59:41 GMT
Subject: RFR: 8315585: Optimization for decimal to string [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 14 Sep 2023 11:19:08 GMT, ???  wrote:

>> BigDecimal is a commonly used class in business development, It is often necessary to perform toString or toPlainString operations on BigDecimal.
>> 
>> The current version uses StringBuilder resulting in multiple memory allocations, I made a modification to improve performance.
>> 
>> Because BigDecimal uses stringCache to cache the result of toString, the performance of toString needs special treatment before testing, such as clearing stringCache by unsafe operation before each test, The performance of toString is similar to that of toEngineering.
>> 
>> The performance data is as follows: 
>> 
>> ## 1. benchmark script
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.math.BigDecimals.*ToPlainString"
>> make test TEST="micro:java.math.BigDecimals.*ToEngineering"
>> 
>> 
>> ## 2. benchmark environment
>> * virtual machine : [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/zh/ecs/user-guide/overview-of-instance-families#c8i)
>> * cpu intel xeon sapphire rapids (x64)
>> 
>> ## 3. benchmark result
>> 
>> -BigDecimals.testHugeToPlainString         avgt   15   188.691 ?  0.822  ns/op  (baseline)
>> -BigDecimals.testLargeToPlainString        avgt   15    36.656 ?  0.065  ns/op
>> -BigDecimals.testSmallToPlainString        avgt   15    34.342 ?  0.068  ns/op
>> -BigDecimals.testToPlainString             avgt   15  1719.494 ? 24.886  ns/op
>> 
>> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
>> +BigDecimals.testHugeToPlainString         avgt   15   133.972 ?  0.328  ns/op (+40.84%)
>> +BigDecimals.testLargeToPlainString        avgt   15    14.957 ?  0.047  ns/op (145.07%)
>> +BigDecimals.testSmallToPlainString        avgt   15    12.045 ?  0.036  ns/op (+185.11)
>> +BigDecimals.testToPlainString             avgt   15  1643.500 ?  3.217  ns/op (+4.62%)
>> 
>> -Benchmark                                 Mode  Cnt     Score    Error  Units (baseline)
>> -BigDecimals.testHugeToEngineeringString   avgt   15   207.621 ?  5.018  ns/op
>> -BigDecimals.testLargeToEngineeringString  avgt   15    35.658 ?  3.144  ns/op
>> -BigDecimals.testSmallToEngineeringString  avgt   15    15.142 ?  0.053  ns/op
>> -BigDecimals.testToEngineeringString       avgt   15  1813.959 ? 12.842  ns/op
>> 
>> +Benchmark                                 Mode  Cnt     Score    Error  Units (optimize)
>> +BigDecimals.testHugeToEngineeringString   avgt   15   142.110 ?  0.987  ns/op (+45.09%)
>> +BigDecimals.testLargeToEngineeringStr...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert JavaLangAccess and use DecimalDigits

BigDecimal#toString is a common scenario. Can anyone help me continue the review? If someone thinks this PR changes too much, I can split it into multiple pull requests.

@cl4es @jddarcy

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15555#issuecomment-1725359433

From rriggs at openjdk.org  Tue Sep 19 14:10:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Sep 2023 14:10:42 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v6]
In-Reply-To: 
References: 
 
 <4o-LifnC7St3sYg1LGniim_KB1_p8AGtx-znLcpbJKg=.17f86862-032c-487e-9f8c-174b094770a4@github.com>
 
Message-ID: 

On Tue, 19 Sep 2023 01:35:49 GMT, ???  wrote:

>> The original (and current) is coded to avoid a condition inside the loop.
>
> I also think that the way of writing for_0 combined with if > 0 is easier to understand, The operation overhead of if > 0 is very small, and it will not affect performance when used in a loop.

The coding pattern to handle first and last special cases outside the loop is also common and may help the JIT with loop unrolling and other optimizations. (And yes JITs can recognize all kinds of code and optimize it anyway).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1330195203

From rriggs at openjdk.org  Tue Sep 19 14:16:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Sep 2023 14:16:43 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v6]
In-Reply-To: 
References: 
 
Message-ID: <0wMcK_ibVlmXPPsw8SSVkw0m3yg1lULdl7vQV0uXnL4=.0962afac-331c-4075-88e0-0414c8c89d30@github.com>

On Tue, 19 Sep 2023 10:41:51 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 two additional commits since the last revision:
> 
>  - update comments
>  - update comments

src/java.base/share/classes/jdk/internal/util/HexDigits.java line 97:

> 95:      * For values from 0 to 256 return a short encoding a pair of hex ASCII-encoded digit characters in little-endian
> 96:      * @param i value to convert
> 97:      * @param ucase ture uppper case, false lower case

"256" -> "255"
"ture" -> "true"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15768#discussion_r1330203208

From duke at openjdk.org  Tue Sep 19 14:30:18 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 19 Sep 2023 14:30:18 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v7]
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:

  fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15768/files
  - new: https://git.openjdk.org/jdk/pull/15768/files/ee78697d..8eff0ee4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 dfuchs at openjdk.org  Tue Sep 19 15:18:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Sep 2023 15:18:44 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 7 Sep 2023 21:50:17 GMT, Tim Prinzing  wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More changes from review:
>   
>   I didn't like the name of the helper method 'checkForCommit' because it
>   doesn't indicate that it might commit the event.  I also don't like
>   'commitEvent' because it might not.  Since JFR events are sort of like a
>   queue I went with a name from collections and called it 'offer' so using
>   it is something like 'SocketReadEvent.offer(...)' which seems like it
>   gets the idea across better.  Also improved the javadoc for it.
>   
>   Removed the comments about being instrumented by JFR in
>   Socket.SocketInputStream and Socket.SocketOutputStream.
>   
>   I went ahead and moved the event commiting out of the finally block so
>   that we don't emit events when the read/write did not actually happen.
>   The bugid JDK-8310979 will be used to determine if more should be done
>   in this area.
>   
>   The implRead and implWrite were moved up with the other support methods
>   for read/write.

LGTM. Are there existing that will help verify that the read events and write events are still emitted as expected? If not shouldn't we write some?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1633551891

From dfuchs at openjdk.org  Tue Sep 19 15:18:45 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Sep 2023 15:18:45 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 7 Sep 2023 21:54:44 GMT, Tim Prinzing  wrote:

> No. I think it's a relic from the distant past though. I think the timeout field should be removed. It's not used on SocketChannel at all, and it doesn't seem useful on Socket.

Should we log an RFE to that effect?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1330294609

From tprinzing at openjdk.org  Tue Sep 19 15:35:11 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 19 Sep 2023 15:35:11 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: 
References: 
Message-ID: 

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8308995
 - More changes from review:
   
   I didn't like the name of the helper method 'checkForCommit' because it
   doesn't indicate that it might commit the event.  I also don't like
   'commitEvent' because it might not.  Since JFR events are sort of like a
   queue I went with a name from collections and called it 'offer' so using
   it is something like 'SocketReadEvent.offer(...)' which seems like it
   gets the idea across better.  Also improved the javadoc for it.
   
   Removed the comments about being instrumented by JFR in
   Socket.SocketInputStream and Socket.SocketOutputStream.
   
   I went ahead and moved the event commiting out of the finally block so
   that we don't emit events when the read/write did not actually happen.
   The bugid JDK-8310979 will be used to determine if more should be done
   in this area.
   
   The implRead and implWrite were moved up with the other support methods
   for read/write.
 - less exception filtering when fetching socket read timeout
 - remove unused SOCKET_READ and SOCKET_WRITE configurations.
 - Merge branch 'master' into JDK-8308995
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
 - Avoid exceptions getting address/timeout for jfr event. Remove unused
   EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
   whitespace.
 - some changes from review.
   
   read0() to implRead()
   write0() to implWrite()
   trailing whitespace
 - fix copyright date
 - Added micro benchmark to measure socket event overhead.
 - Some changes from review.
   
   Append a 0 to method names being wrapped.  Use getHostString to avoid
   a reverse lookup when fetching the hostname of the remote address.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/607bd4ed...6db6fab4

-------------

Changes: https://git.openjdk.org/jdk/pull/14342/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=05
  Stats: 906 lines in 13 files changed: 519 ins; 379 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342

PR: https://git.openjdk.org/jdk/pull/14342

From rriggs at openjdk.org  Tue Sep 19 16:17:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Sep 2023 16:17:42 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v4]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Wed, 13 Sep 2023 14:08:15 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1726019081

From rriggs at openjdk.org  Tue Sep 19 16:30:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Sep 2023 16:30:51 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: <1Sa-6-z846mIOS7Jw5pWTia7NhEjzjX-xOqWQCNI6g0=.5738194e-0996-49b5-8009-9a2e6e551c6c@github.com>

On Wed, 13 Sep 2023 14:22:35 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify LocalDate::getChars

Lots of adhoc changes bulk up the source and make it less maintainable.
Given the common element of time and date formatting strings as a domain specific language, there would be more benefit to leveraging one of several existing mechanisms to generate optimized formatters from application or library format strings.
For example, the general purpose [JEP 430: String Template](https://openjdk.org/jeps/430)s could be used to compose the string and leverage its optimizations of formatting the components.
Making improvements there either to performance or functionality would benefit more applications.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1726038572

From joehw at openjdk.org  Tue Sep 19 16:35:54 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 19 Sep 2023 16:35:54 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 18:33:20 GMT, Naoto Sato  wrote:

>> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Fix GensrcRegex.gmk
>  - Merge branch 'master' into JDK-8296246-Unicode15.1
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - TR29 final version
>  - .md file update
>  - Final 8/28
>  - Draft 8/11
>  - GenerateExtraProperties tool
>  - initial commit

LGTM. A couple of minor suggestions.

make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java line 41:

> 39: /**
> 40:  * Parses extra properties files of UCD, and replaces the placeholders in
> 41:  * the given template source file with the generated conditions, then emit

s/emit/emits?

make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java line 51:

> 49:  * 

> 50:  *     %%%Type(=Value)%%%
> 51:  * 


Nice example to explain how it works! 
I wonder if it might be helpful to clarify that the () indicate optional. It could be slightly confused with being a part of the template.

make/modules/java.base/gensrc/GensrcRegex.gmk line 35:

> 33: INDICCONJUNCTBREAKTEMP := $(MODULE_SRC)/share/classes/jdk/internal/util/regex/IndicConjunctBreak.java.template
> 34: INDICCONJUNCTBREAKPROPS := $(MODULE_SRC)/share/data/unicodedata/DerivedCoreProperties.txt
> 35: INDICCONJUNCTBREAKPARAMS := InCB=Linker InCB=Extend InCB=Consonant

DerivedCoreProperties.txt is very large. Would it be helpful to reference the section, that is "Derived Property: Indic_Conjunct_Break", in this file or the template?

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15728#pullrequestreview-1633706039
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330390702
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330408135
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330410613

From Alan.Bateman at oracle.com  Tue Sep 19 16:41:59 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Sep 2023 17:41:59 +0100
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: 
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
 
Message-ID: <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>

On 18/09/2023 14:51, Andrew Leonard wrote:
> Thanks for the clarification Alan.
>
> To ensure the reproducibility of the whole JDK image regardless of the 
> specific bootjdk used, would it make sense once the "Build JDK" has 
> been built, we re-build jrt-fs.jar again using the "Build JDK" ? Thus 
> jrt-fs.jar will be consistent with the rest of the image in terms of 
> what it is compiled with.
>

The boot JDK will be JDK N-1, or the newly built JDK in the case of boot 
cycle builds. It seems a bit of a stretch to have builds using different 
tool chains to produce identical bits but maybe you mean something else.

In any case, for jrt-fs.jar the important thing is that they are 
compiled to --release 8 (that might rev at some points) so that 
IDEs/tools can open a target run-time image as a file system and access 
the classes/resources.

-Alan.

From naoto at openjdk.org  Tue Sep 19 16:55:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 16:55:46 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 22:42:09 GMT, Justin Lu  wrote:

> Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations.
> 
> As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).
> 
> 
> This system has the following structure,
> 
> `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
> (`Gregorian, JulianCalendar, LocalGregorianCalendar`)
> 
> `CalendarDate` extended by `BaseCalendar.Date` extended by 
> (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)
> 
> Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.

Looks good overall.

src/java.base/share/classes/sun/util/calendar/CalendarUtils.java line 30:

> 28: public final class CalendarUtils {
> 29: 
> 30:     private CalendarUtils() {}

It may be obvious, but adding a comment would be helpful, i.e., no instance may be created.

src/java.base/share/classes/sun/util/calendar/CalendarUtils.java line 132:

> 130:      * Mimics sprintf(buf, "%0*d", decaimal, width).
> 131:      */
> 132:     public static StringBuilder sprintf0d(StringBuilder sb, int value, int width) {

Can this (and the following overload) method be eliminated? No need to mimic `sprintf` here, but using `String.format`/`formatted` should suffice?

src/java.base/share/classes/sun/util/calendar/Gregorian.java line 40:

> 38: 
> 39:     static final class Date extends BaseCalendar.Date {
> 40:         Date() {

I think removing `protected` from the `final` class methods is fine. Adding `@Override` may be helpful.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15803#pullrequestreview-1633738951
PR Review Comment: https://git.openjdk.org/jdk/pull/15803#discussion_r1330414349
PR Review Comment: https://git.openjdk.org/jdk/pull/15803#discussion_r1330430127
PR Review Comment: https://git.openjdk.org/jdk/pull/15803#discussion_r1330418996

From srl at openjdk.org  Tue Sep 19 17:02:48 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 19 Sep 2023 17:02:48 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: <6jYA8vdyb0LsOl_cvwNRe7qD-4WHpvpJLACRCVVtLSo=.3f23846a-08cc-453b-a674-a7a2b5aa8f6c@github.com>
References: 
 
 <6jYA8vdyb0LsOl_cvwNRe7qD-4WHpvpJLACRCVVtLSo=.3f23846a-08cc-453b-a674-a7a2b5aa8f6c@github.com>
Message-ID: 

On Tue, 19 Sep 2023 16:57:57 GMT, Steven Loomis  wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Fix GensrcRegex.gmk
>>  - Merge branch 'master' into JDK-8296246-Unicode15.1
>>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>>    
>>    Co-authored-by: Andrey Turbanov 
>>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>>    
>>    Co-authored-by: Andrey Turbanov 
>>  - TR29 final version
>>  - .md file update
>>  - Final 8/28
>>  - Draft 8/11
>>  - GenerateExtraProperties tool
>>  - initial commit
>
> src/java.base/share/legal/unicode.md line 49:
> 
>> 47: ------------------
>> 48: 
>> 49: Unicode? Copyright and Terms of Use
> 
> You shouldn't need to pull in all of this ??the entire license file is at https://www.unicode.org/license.txt 
> 
> It looks like you are pulling in all of https://www.unicode.org/copyright.html
> 
> You will notice that the license text no longer points you to https://www.unicode.org/copyright.html
> 
> (I worked on this change a bit)

look at https://www.unicode.org/Public/UCD/latest/ for example, it points you only to license.txt.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330445143

From srl at openjdk.org  Tue Sep 19 17:02:46 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 19 Sep 2023 17:02:46 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: 
References: 
 
Message-ID: <6jYA8vdyb0LsOl_cvwNRe7qD-4WHpvpJLACRCVVtLSo=.3f23846a-08cc-453b-a674-a7a2b5aa8f6c@github.com>

On Mon, 18 Sep 2023 18:33:20 GMT, Naoto Sato  wrote:

>> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Fix GensrcRegex.gmk
>  - Merge branch 'master' into JDK-8296246-Unicode15.1
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - TR29 final version
>  - .md file update
>  - Final 8/28
>  - Draft 8/11
>  - GenerateExtraProperties tool
>  - initial commit

Marked as reviewed by srl (Committer).

make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java line 42:

> 40:  * Parses extra properties files of UCD, and replaces the placeholders in
> 41:  * the given template source file with the generated conditions, then emit
> 42:  * the produced .java files. For example, if the properties file has:

Suggestion:

 * Parses extra properties files of UCD, and replaces the placeholders in
 * the given template source file with the generated conditions, then emits
 * .java files. For example, if the properties file has:

src/java.base/share/legal/unicode.md line 6:

> 4: ```
> 5: 
> 6: UNICODE LICENSE V3

very  minor update

src/java.base/share/legal/unicode.md line 49:

> 47: ------------------
> 48: 
> 49: Unicode? Copyright and Terms of Use

You shouldn't need to pull in all of this ??the entire license file is at https://www.unicode.org/license.txt 

It looks like you are pulling in all of https://www.unicode.org/copyright.html

You will notice that the license text no longer points you to https://www.unicode.org/copyright.html

(I worked on this change a bit)

-------------

PR Review: https://git.openjdk.org/jdk/pull/15728#pullrequestreview-1633772463
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330434732
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330439566
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330441674

From srl at openjdk.org  Tue Sep 19 17:23:40 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 19 Sep 2023 17:23:40 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 22:42:09 GMT, Justin Lu  wrote:

> Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations.
> 
> As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).
> 
> 
> This system has the following structure,
> 
> `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
> (`Gregorian, JulianCalendar, LocalGregorianCalendar`)
> 
> `CalendarDate` extended by `BaseCalendar.Date` extended by 
> (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)
> 
> Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.

I added a question on https://bugs.openjdk.org/browse/JDK-8316435 as to the effect on future calendar systems.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15803#issuecomment-1726166576

From lmesnik at openjdk.org  Tue Sep 19 17:31:08 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Sep 2023 17:31:08 GMT
Subject: RFR: 8316445: Mark
 com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java as vm.flagless
Message-ID: 

Test
com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
check how beans work with VM flags and ignore external flags.
It doesn't make sense to run it with external options so just mark it as flagless.
Tested with running tier1 and test with/without additional options.

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/15823/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15823&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316445
  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15823.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15823/head:pull/15823

PR: https://git.openjdk.org/jdk/pull/15823

From alanb at openjdk.org  Tue Sep 19 17:41:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 17:41:43 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 10 Aug 2023 17:21:31 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 two additional commits since the last revision:
> 
>  - 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.

I did a pass over this to see where this proposal is currently at. At a high-level I think good progress since the discussion on leyden-dev some time ago. A few comments this from this pass:

If I read it correctly, the default behavior is now to fail if jlink is executed from a run-time image that has been modified from the original and the packaged modules are not observable on the module path (this includes the default module path effectively appended by jlink). That seems the right policy as it avoids modifications by plugins or conf changes silently propagating.

If I read the code correctly, the error when a hash doesn't match is a very terse "Run image links only allow single-hop" so that probably needs to be looked to make sure the message says that the run-time image has been modified and maybe include one of the files/resources that has changed so there is something real to go with the error.

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 (I suspect "single hop" won't be understood).

Adding a new jdk.tools.jlink.internal.Archive implementation where the resources come from the run-time image seems a sensible approach. I don't particularly like the name "JmodLessArchive" because the original module may not have been packaged as a JMOD file, it may have been a modular JAR. Same comment on the BOM file "jmod_resources" added to the top-level directory of each module. I think it's clever to add this to each module in the container image but part of me wonders if it should be hidden in some way to avoid tools depending on it. I don't have a concrete suggestion except to wonder if jrtfs should filter it out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1726205365

From rriggs at openjdk.org  Tue Sep 19 18:11:46 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Sep 2023 18:11:46 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: 
References: 
 
Message-ID: <4poYIGyAklTUdvWD6LIVKf4YD8sDh4HQO3tAXJvUwI8=.c664b458-43ab-4ed6-aa08-1612b259ef2b@github.com>

On Mon, 18 Sep 2023 18:33:20 GMT, Naoto Sato  wrote:

>> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Fix GensrcRegex.gmk
>  - Merge branch 'master' into JDK-8296246-Unicode15.1
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>    
>    Co-authored-by: Andrey Turbanov 
>  - TR29 final version
>  - .md file update
>  - Final 8/28
>  - Draft 8/11
>  - GenerateExtraProperties tool
>  - initial commit

Looks good;  Its not easy to map all the code changes to spec changes.

src/java.base/share/classes/jdk/internal/util/regex/Grapheme.java line 41:

> 39:      * (http://www.unicode.org/reports/tr29/tr29-43.html)
> 40:      *
> 41:      * @spec http://www.unicode.org/reports/tr29/tr29-43.html

Is the first link now redundant with the @spec link?

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15728#pullrequestreview-1633892125
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330509464

From jlu at openjdk.org  Tue Sep 19 18:21:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Sep 2023 18:21:41 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing
In-Reply-To: 
References: 
Message-ID: <0alx86jS3MrF7a0gEtUN7Wgm8J70tfBflpSDSBDlvTc=.4875ab96-5168-48c3-8c53-7cca1f0375c8@github.com>

On Tue, 19 Sep 2023 01:01:14 GMT, Naoto Sato  wrote:

> Fixed the failing (well, false-positive) test case. Made the following changes to the test:
> 
> - Corrected the path to the mapping files directory
> - Made sure to fail if the directory path is incorrect
> - Took care of `GB18030` alias, which is dynamically derived at runtime
> - Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
> - Excluded other failing tests for IBM charsets that do not have map files.

Actually tests 138 charsets now, looks good

test/jdk/sun/nio/cs/TestCharsetMapping.java line 574:

> 572:             "/../../../../../make/data/charsetmapping");
> 573:         if (!Files.exists(dir)) {
> 574:             throw new Exception("charsetmapping directory cannot be located.");

Might be helpful to provide directory location in exception message

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15807#pullrequestreview-1633923524
PR Review Comment: https://git.openjdk.org/jdk/pull/15807#discussion_r1330529497

From xqoasis at openjdk.org  Tue Sep 19 18:30:10 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Tue, 19 Sep 2023 18:30:10 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests [v4]
In-Reply-To: 
References: 
Message-ID: 

> Modified all tests under lib-test/jdk to use JUnit

Qing Xiao has updated the pull request incrementally with three additional commits since the last revision:

 - Update test/lib-test/jdk/test/lib/hexdump/ObjectStreamPrinterTest.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Update test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Update test/lib-test/jdk/test/lib/format/ArrayDiffTest.java
   
   Co-authored-by: Christian Stein 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15131/files
  - new: https://git.openjdk.org/jdk/pull/15131/files/e520735d..7043c900

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15131&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15131&range=02-03

  Stats: 3 lines in 3 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15131/head:pull/15131

PR: https://git.openjdk.org/jdk/pull/15131

From naoto at openjdk.org  Tue Sep 19 18:34:38 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 18:34:38 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
  
  Co-authored-by: Steven R. Loomis 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15728/files
  - new: https://git.openjdk.org/jdk/pull/15728/files/31e397ce..415418f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15728&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15728&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15728/head:pull/15728

PR: https://git.openjdk.org/jdk/pull/15728

From duke at openjdk.org  Tue Sep 19 18:40:44 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 19 Sep 2023 18:40:44 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased
In-Reply-To: 
References: 
Message-ID: <8fOcDAP-yNMbgd_SLIAlrYCmKwGQWvo2NeJX3CnW8n8=.753376b5-1bf1-4e25-8459-4bf138ad8b1e@github.com>

On Thu, 7 Sep 2023 11:13:44 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.

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1330553732

From naoto at openjdk.org  Tue Sep 19 18:55:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 18:55:28 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. 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/15728/files
  - new: https://git.openjdk.org/jdk/pull/15728/files/415418f0..0ae0c45f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15728&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15728&range=03-04

  Stats: 6 lines in 3 files changed: 5 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15728/head:pull/15728

PR: https://git.openjdk.org/jdk/pull/15728

From srl at openjdk.org  Tue Sep 19 18:55:49 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 19 Sep 2023 18:55:49 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 18:55:28 GMT, Naoto Sato  wrote:

>> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. 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 srl (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15728#pullrequestreview-1633987334

From naoto at openjdk.org  Tue Sep 19 18:55:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 18:55:55 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 19 Sep 2023 16:18:18 GMT, Joe Wang  wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Fix GensrcRegex.gmk
>>  - Merge branch 'master' into JDK-8296246-Unicode15.1
>>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>>    
>>    Co-authored-by: Andrey Turbanov 
>>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>>    
>>    Co-authored-by: Andrey Turbanov 
>>  - TR29 final version
>>  - .md file update
>>  - Final 8/28
>>  - Draft 8/11
>>  - GenerateExtraProperties tool
>>  - initial commit
>
> make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java line 41:
> 
>> 39: /**
>> 40:  * Parses extra properties files of UCD, and replaces the placeholders in
>> 41:  * the given template source file with the generated conditions, then emit
> 
> s/emit/emits?

Thanks. Fixed it along with @srl295 's suggestion

> make/modules/java.base/gensrc/GensrcRegex.gmk line 35:
> 
>> 33: INDICCONJUNCTBREAKTEMP := $(MODULE_SRC)/share/classes/jdk/internal/util/regex/IndicConjunctBreak.java.template
>> 34: INDICCONJUNCTBREAKPROPS := $(MODULE_SRC)/share/data/unicodedata/DerivedCoreProperties.txt
>> 35: INDICCONJUNCTBREAKPARAMS := InCB=Linker InCB=Extend InCB=Consonant
> 
> DerivedCoreProperties.txt is very large. Would it be helpful to reference the section, that is "Derived Property: Indic_Conjunct_Break", in this file or the template?

Added explanation in `IndicConjunctBreak.java.template`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330570147
PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330570225

From naoto at openjdk.org  Tue Sep 19 18:55:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 18:55:57 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: <4poYIGyAklTUdvWD6LIVKf4YD8sDh4HQO3tAXJvUwI8=.c664b458-43ab-4ed6-aa08-1612b259ef2b@github.com>
References: 
 
 <4poYIGyAklTUdvWD6LIVKf4YD8sDh4HQO3tAXJvUwI8=.c664b458-43ab-4ed6-aa08-1612b259ef2b@github.com>
Message-ID: 

On Tue, 19 Sep 2023 17:54:52 GMT, Roger Riggs  wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Fix GensrcRegex.gmk
>>  - Merge branch 'master' into JDK-8296246-Unicode15.1
>>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>>    
>>    Co-authored-by: Andrey Turbanov 
>>  - Update make/jdk/src/classes/build/tools/generateextraproperties/GenerateExtraProperties.java
>>    
>>    Co-authored-by: Andrey Turbanov 
>>  - TR29 final version
>>  - .md file update
>>  - Final 8/28
>>  - Draft 8/11
>>  - GenerateExtraProperties tool
>>  - initial commit
>
> src/java.base/share/classes/jdk/internal/util/regex/Grapheme.java line 41:
> 
>> 39:      * (http://www.unicode.org/reports/tr29/tr29-43.html)
>> 40:      *
>> 41:      * @spec http://www.unicode.org/reports/tr29/tr29-43.html
> 
> Is the first link now redundant with the @spec link?

Thanks, removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330570348

From naoto at openjdk.org  Tue Sep 19 18:55:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 18:55:59 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: 
References: 
 
 <6jYA8vdyb0LsOl_cvwNRe7qD-4WHpvpJLACRCVVtLSo=.3f23846a-08cc-453b-a674-a7a2b5aa8f6c@github.com>
 
Message-ID: 

On Tue, 19 Sep 2023 17:00:39 GMT, Steven Loomis  wrote:

>> src/java.base/share/legal/unicode.md line 49:
>> 
>>> 47: ------------------
>>> 48: 
>>> 49: Unicode? Copyright and Terms of Use
>> 
>> You shouldn't need to pull in all of this ??the entire license file is at https://www.unicode.org/license.txt 
>> 
>> It looks like you are pulling in all of https://www.unicode.org/copyright.html
>> 
>> You will notice that the license text no longer points you to https://www.unicode.org/copyright.html
>> 
>> (I worked on this change a bit)
>
> look at https://www.unicode.org/Public/UCD/latest/ for example, it points you only to license.txt.

We are checking on it and will update it if necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330570307

From srl at openjdk.org  Tue Sep 19 18:59:43 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 19 Sep 2023 18:59:43 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v3]
In-Reply-To: 
References: 
 
 <6jYA8vdyb0LsOl_cvwNRe7qD-4WHpvpJLACRCVVtLSo=.3f23846a-08cc-453b-a674-a7a2b5aa8f6c@github.com>
 
 
Message-ID: 

On Tue, 19 Sep 2023 18:53:30 GMT, Naoto Sato  wrote:

>> look at https://www.unicode.org/Public/UCD/latest/ for example, it points you only to license.txt.
>
> We are checking on it and will update it if necessary.

it was unnecessary to mention copyright.html or terms of use in the source license previously

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15728#discussion_r1330573202

From naoto at openjdk.org  Tue Sep 19 20:03:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 20:03:51 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing [v2]
In-Reply-To: 
References: 
Message-ID: 

> Fixed the failing (well, false-positive) test case. Made the following changes to the test:
> 
> - Corrected the path to the mapping files directory
> - Made sure to fail if the directory path is incorrect
> - Took care of `GB18030` alias, which is dynamically derived at runtime
> - Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
> - Excluded other failing tests for IBM charsets that do not have map files.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Included the failed directory location in the exception message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15807/files
  - new: https://git.openjdk.org/jdk/pull/15807/files/e2731ff8..6d28a5ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15807&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15807&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15807/head:pull/15807

PR: https://git.openjdk.org/jdk/pull/15807

From naoto at openjdk.org  Tue Sep 19 20:03:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 20:03:54 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing [v2]
In-Reply-To: <0alx86jS3MrF7a0gEtUN7Wgm8J70tfBflpSDSBDlvTc=.4875ab96-5168-48c3-8c53-7cca1f0375c8@github.com>
References: 
 <0alx86jS3MrF7a0gEtUN7Wgm8J70tfBflpSDSBDlvTc=.4875ab96-5168-48c3-8c53-7cca1f0375c8@github.com>
Message-ID: 

On Tue, 19 Sep 2023 18:15:54 GMT, Justin Lu  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Included the failed directory location in the exception message
>
> test/jdk/sun/nio/cs/TestCharsetMapping.java line 574:
> 
>> 572:             "/../../../../../make/data/charsetmapping");
>> 573:         if (!Files.exists(dir)) {
>> 574:             throw new Exception("charsetmapping directory cannot be located.");
> 
> Might be helpful to provide directory location in exception message

Good point. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15807#discussion_r1330639943

From aturbanov at openjdk.org  Tue Sep 19 20:22:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 19 Sep 2023 20:22:05 GMT
Subject: RFR: 8316557: Make fields final in 'sun.util' package
Message-ID: 

A few classes in `sun.util` package have non-final fields which could easily be marked `final`.

-------------

Commit messages:
 - [PATCH] Make fields final in 'sun.util' package

Changes: https://git.openjdk.org/jdk/pull/15736/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316557
  Stats: 42 lines in 10 files changed: 2 ins; 13 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/15736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15736/head:pull/15736

PR: https://git.openjdk.org/jdk/pull/15736

From liach at openjdk.org  Tue Sep 19 20:22:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Sep 2023 20:22:06 GMT
Subject: RFR: 8316557: Make fields final in 'sun.util' package
In-Reply-To: 
References: 
Message-ID: 

On Thu, 14 Sep 2023 08:58:56 GMT, Andrey Turbanov  wrote:

> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/sun/util/PropertyResourceBundleCharset.java line 71:

> 69:     private final class PropertiesFileDecoder extends CharsetDecoder {
> 70: 
> 71:         private final CharsetDecoder cdUTF_8 = UTF_8.INSTANCE.newDecoder()

Can be static as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1328836367

From asemenyuk at openjdk.org  Tue Sep 19 20:23:30 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Sep 2023 20:23:30 GMT
Subject: RFR: 8316547: Use JUnit.dir jtreg property with jpackage JUnit tests
Message-ID: 

Strip

/*
 * @test
 * @modules jdk.jpackage
 * @compile --patch-module jdk.jpackage=${test.src} --add-reads jdk.jpackage=ALL-UNNAMED --add-exports jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED AppImageFileTest.java
 * @run junit/othervm --patch-module jdk.jpackage=${test.classes} --add-reads jdk.jpackage=ALL-UNNAMED --add-exports jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED jdk.jpackage.internal.AppImageFileTest
 */

comment from jpackage JUnit tests and instruct jtreg to run them through `JUnit.dirs` property.

-------------

Commit messages:
 - 8316547: Use JUnit.dir jtreg property with jpackage JUnit tests

Changes: https://git.openjdk.org/jdk/pull/15826/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15826&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316547
  Stats: 1407 lines in 19 files changed: 669 ins; 735 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15826/head:pull/15826

PR: https://git.openjdk.org/jdk/pull/15826

From rriggs at openjdk.org  Tue Sep 19 20:26:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Sep 2023 20:26:44 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v4]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
Message-ID: 

On Fri, 15 Sep 2023 21:51:22 GMT, Brian Burkhalter  wrote:

>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315960: Remove vestigial unused import

test/jdk/java/io/File/TempDirDoesNotExist.java line 53:

> 51:     private static final String USER_DIR = System.getProperty("user.home");
> 52: 
> 53:     public static void main(String... args) throws IOException {

Might be worth a comment that this is spawned to test combinations of parameters.

test/jdk/java/io/File/TempDirDoesNotExist.java line 55:

> 53:     public static void main(String... args) throws IOException {
> 54:         for (String arg : args) {
> 55:             if (arg.equals("io")) {

Maybe use switch on string instead of `if...else...`; a bit more compact.

test/jdk/java/io/File/TempDirDoesNotExist.java line 132:

> 130:                                           "io"
> 131:                                       });
> 132:         list.add(args);

You can use 

Stream.of( Arguments.of(..),
           Arguments.of(...),
           ...);

A bit more compact and without the explicit arglist.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330656123
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330657821
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330663053

From joehw at openjdk.org  Tue Sep 19 20:36:42 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 19 Sep 2023 20:36:42 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 18:55:28 GMT, Naoto Sato  wrote:

>> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. 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 joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15728#pullrequestreview-1634146771

From joehw at openjdk.org  Tue Sep 19 20:37:40 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 19 Sep 2023 20:37:40 GMT
Subject: RFR: 8296246: Update Unicode Data Files to Version 15.1.0 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 18:55:28 GMT, Naoto Sato  wrote:

>> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. 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 joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15728#pullrequestreview-1634146771

From jlu at openjdk.org  Tue Sep 19 20:53:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Sep 2023 20:53:38 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted [v2]
In-Reply-To: 
References: 
Message-ID: <807sUZYzupjQ2O4TYV1jR7WLRJ_t90i2RHtulFg8YO4=.2a089bcc-c47a-42f8-a3f3-d73e7fd968bb@github.com>

> Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations. Drive by cleanup included.
> 
> As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).
> 
> 
> This system has the following structure,
> 
> `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
> (`Gregorian, JulianCalendar, LocalGregorianCalendar`)
> 
> `CalendarDate` extended by `BaseCalendar.Date` extended by 
> (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)
> 
> Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.

Justin Lu has updated the pull request incrementally with six additional commits since the last revision:

 - Replace sprintf0d with Formatter
 - setCache should not be overridden to be unsupported in IGD
 - Cleanup immutableGreg
 - Clarify the class with comments, also overide setCache to throw an exception
 - Use Override annotation within calendar system
 - Clarify private constructor with comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15803/files
  - new: https://git.openjdk.org/jdk/pull/15803/files/b6915efe..84a346ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15803&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15803&range=00-01

  Stats: 185 lines in 11 files changed: 95 ins; 48 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/15803.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15803/head:pull/15803

PR: https://git.openjdk.org/jdk/pull/15803

From bpb at openjdk.org  Tue Sep 19 20:53:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 20:53:44 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v5]
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: 

> Add a `finally` block to delete the created files.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8315960: Improve test as suggested by Reviewer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15757/files
  - new: https://git.openjdk.org/jdk/pull/15757/files/f940caed..cab8fa50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=03-04

  Stats: 82 lines in 1 file changed: 9 ins; 30 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/15757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15757/head:pull/15757

PR: https://git.openjdk.org/jdk/pull/15757

From tprinzing at openjdk.org  Tue Sep 19 20:54:48 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 19 Sep 2023 20:54:48 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 15:35:11 GMT, Tim Prinzing  wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into JDK-8308995
>  - More changes from review:
>    
>    I didn't like the name of the helper method 'checkForCommit' because it
>    doesn't indicate that it might commit the event.  I also don't like
>    'commitEvent' because it might not.  Since JFR events are sort of like a
>    queue I went with a name from collections and called it 'offer' so using
>    it is something like 'SocketReadEvent.offer(...)' which seems like it
>    gets the idea across better.  Also improved the javadoc for it.
>    
>    Removed the comments about being instrumented by JFR in
>    Socket.SocketInputStream and Socket.SocketOutputStream.
>    
>    I went ahead and moved the event commiting out of the finally block so
>    that we don't emit events when the read/write did not actually happen.
>    The bugid JDK-8310979 will be used to determine if more should be done
>    in this area.
>    
>    The implRead and implWrite were moved up with the other support methods
>    for read/write.
>  - less exception filtering when fetching socket read timeout
>  - remove unused SOCKET_READ and SOCKET_WRITE configurations.
>  - Merge branch 'master' into JDK-8308995
>    
>    # Conflicts:
>    #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
>  - Avoid exceptions getting address/timeout for jfr event. Remove unused
>    EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
>    whitespace.
>  - some changes from review.
>    
>    read0() to implRead()
>    write0() to implWrite()
>    trailing whitespace
>  - fix copyright date
>  - Added micro benchmark to measure socket event overhead.
>  - Some changes from review.
>    
>    Append a 0 to method names being wrapped.  Use getHostString to avoid
>    a reverse lookup when fetching the hostname of the remote address.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/607bd4ed...6db6fab4

I sync'd master and updated the bug report with the successful test results.

Created [JDK-8316558] to track potential timeout field removal.  

The existing JFR tests TestSocketChannelEvents and TestSocketEvents in jdk.jfr.event.io verify the events are still emitted as expected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1726449349

From bpb at openjdk.org  Tue Sep 19 20:58:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 20:58:43 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v4]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
 
Message-ID: <3qHK1QgmFpZds6yo4JN7CmiaA6L08wrqwy4kvHA8-7c=.e95b279d-36a8-45b5-81ca-8e43d6c66971@github.com>

On Tue, 19 Sep 2023 20:15:18 GMT, Roger Riggs  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8315960: Remove vestigial unused import
>
> test/jdk/java/io/File/TempDirDoesNotExist.java line 53:
> 
>> 51:     private static final String USER_DIR = System.getProperty("user.home");
>> 52: 
>> 53:     public static void main(String... args) throws IOException {
> 
> Might be worth a comment that this is spawned to test combinations of parameters.

Comment added in cab8fa50a848f3c796bc81adcfd214aef0d054d3.

> test/jdk/java/io/File/TempDirDoesNotExist.java line 132:
> 
>> 130:                                           "io"
>> 131:                                       });
>> 132:         list.add(args);
> 
> You can use 
> 
> Stream.of( Arguments.of(..),
>            Arguments.of(...),
>            ...);
> 
> A bit more compact and without the explicit arglist.

So changed in cab8fa50a848f3c796bc81adcfd214aef0d054d3.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330689736
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330689634

From naoto at openjdk.org  Tue Sep 19 20:58:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 20:58:45 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v4]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
Message-ID: 

On Fri, 15 Sep 2023 21:51:22 GMT, Brian Burkhalter  wrote:

>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315960: Remove vestigial unused import

test/jdk/java/io/File/TempDirDoesNotExist.java line 192:

> 190:         OutputAnalyzer originalOutput = ProcessTools.executeTestJvm(options);
> 191:         List list = originalOutput.asLines().stream().filter(line
> 192:                 -> line.equalsIgnoreCase(WARNING)).collect(Collectors.toList());

`Stream.toList()` can be applied here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330691571

From almatvee at openjdk.org  Tue Sep 19 21:11:40 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 19 Sep 2023 21:11:40 GMT
Subject: RFR: 8316547: Use JUnit.dir jtreg property with jpackage JUnit
 tests
In-Reply-To: 
References: 
Message-ID: 

On Tue, 19 Sep 2023 20:15:20 GMT, Alexey Semenyuk  wrote:

> Strip
> 
> /*
>  * @test
>  * @modules jdk.jpackage
>  * @compile --patch-module jdk.jpackage=${test.src} --add-reads jdk.jpackage=ALL-UNNAMED --add-exports jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED AppImageFileTest.java
>  * @run junit/othervm --patch-module jdk.jpackage=${test.classes} --add-reads jdk.jpackage=ALL-UNNAMED --add-exports jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED jdk.jpackage.internal.AppImageFileTest
>  */
> 
> comment from jpackage JUnit tests and instruct jtreg to run them through `JUnit.dirs` property.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15826#pullrequestreview-1634191968

From jlu at openjdk.org  Tue Sep 19 21:14:04 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Sep 2023 21:14:04 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations. Drive by cleanup included.
> 
> As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).
> 
> 
> This system has the following structure,
> 
> `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
> (`Gregorian, JulianCalendar, LocalGregorianCalendar`)
> 
> `CalendarDate` extended by `BaseCalendar.Date` extended by 
> (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)
> 
> Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Re-import Locale after merge for Formatter
 - Merge master
 - Replace sprintf0d with Formatter
 - setCache should not be overridden to be unsupported in IGD
 - Cleanup immutableGreg
 - Clarify the class with comments, also overide setCache to throw an exception
 - Use Override annotation within calendar system
 - Clarify private constructor with comment
 - private constructor in CalendarUtils
 - Make utility class 'CalendarUtils' final
 - ... and 5 more: https://git.openjdk.org/jdk/compare/373e37bf...f8698724

-------------

Changes: https://git.openjdk.org/jdk/pull/15803/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15803&range=02
  Stats: 222 lines in 12 files changed: 101 ins; 48 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/15803.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15803/head:pull/15803

PR: https://git.openjdk.org/jdk/pull/15803

From jlu at openjdk.org  Tue Sep 19 21:14:05 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Sep 2023 21:14:05 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 16:48:54 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Re-import Locale after merge for Formatter
>>  - Merge master
>>  - Replace sprintf0d with Formatter
>>  - setCache should not be overridden to be unsupported in IGD
>>  - Cleanup immutableGreg
>>  - Clarify the class with comments, also overide setCache to throw an exception
>>  - Use Override annotation within calendar system
>>  - Clarify private constructor with comment
>>  - private constructor in CalendarUtils
>>  - Make utility class 'CalendarUtils' final
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/373e37bf...f8698724
>
> src/java.base/share/classes/sun/util/calendar/CalendarUtils.java line 132:
> 
>> 130:      * Mimics sprintf(buf, "%0*d", decaimal, width).
>> 131:      */
>> 132:     public static StringBuilder sprintf0d(StringBuilder sb, int value, int width) {
> 
> Can this (and the following overload) method be eliminated? No need to mimic `sprintf` here, but using `String.format`/`formatted` should suffice?

Thanks for reviewing, replaced the two methods with Formatter (there are occurrences in _test_ as well)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15803#discussion_r1330703923

From joehw at openjdk.org  Tue Sep 19 21:19:11 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 19 Sep 2023 21:19:11 GMT
Subject: RFR: 8316383: NullPointerException in AbstractSAXParser after
 JDK-8306632
Message-ID: 

Fix a NPE. The DTD patch (JDK-8306632) moved initialization to factories, for example, for SAXParser, the SecurityManagers are created in the SAXParserFactory impl and passed on to instances of SAXParsers. The (deprecated) XMLReaderFactory however, instantiates SAXParsers directly, thus without initializing the SecurityManagers. This patch checks the condition and creates them if they have not already been constructed.

Test: XML tests passed.

-------------

Commit messages:
 - 8316383: NullPointerException in AbstractSAXParser after JDK-8306632

Changes: https://git.openjdk.org/jdk/pull/15828/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15828&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316383
  Stats: 78 lines in 3 files changed: 65 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15828.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15828/head:pull/15828

PR: https://git.openjdk.org/jdk/pull/15828

From bpb at openjdk.org  Tue Sep 19 21:19:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 21:19:45 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v5]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
 
Message-ID: 

On Tue, 19 Sep 2023 21:15:36 GMT, Roger Riggs  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8315960: Improve test as suggested by Reviewer
>
> test/jdk/java/io/File/TempDirDoesNotExist.java line 118:
> 
>> 116:     }
>> 117: 
>> 118:     public static Stream nonexistentProvider() {
> 
> The `nonexistentProvider` seems like an odd name. The only provider here is the junit provider (not a FileSystem provider)
> How about `NoTempDir` and `TempDir` for the two argument streams.

That definitely sounds more reasonable. Unfortunate nomenclature on my part.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330710517

From rriggs at openjdk.org  Tue Sep 19 21:19:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Sep 2023 21:19:44 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v5]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
Message-ID: 

On Tue, 19 Sep 2023 20:53:44 GMT, Brian Burkhalter  wrote:

>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315960: Improve test as suggested by Reviewer

test/jdk/java/io/File/TempDirDoesNotExist.java line 118:

> 116:     }
> 117: 
> 118:     public static Stream nonexistentProvider() {

The `nonexistentProvider` seems like an odd name. The only provider here is the junit provider (not a FileSystem provider)
How about `NoTempDir` and `TempDir` for the two argument streams.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330708013

From jlu at openjdk.org  Tue Sep 19 21:24:24 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Sep 2023 21:24:24 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations. Drive by cleanup included.
> 
> As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).
> 
> 
> This system has the following structure,
> 
> `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
> (`Gregorian, JulianCalendar, LocalGregorianCalendar`)
> 
> `CalendarDate` extended by `BaseCalendar.Date` extended by 
> (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)
> 
> Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Use pattern matching instanceof in equals for IGD

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15803/files
  - new: https://git.openjdk.org/jdk/pull/15803/files/f8698724..790f7506

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15803&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15803&range=02-03

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15803.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15803/head:pull/15803

PR: https://git.openjdk.org/jdk/pull/15803

From bpb at openjdk.org  Tue Sep 19 21:26:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 21:26:40 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v5]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
 
 
Message-ID: 

On Tue, 19 Sep 2023 21:17:02 GMT, Brian Burkhalter  wrote:

>> test/jdk/java/io/File/TempDirDoesNotExist.java line 118:
>> 
>>> 116:     }
>>> 117: 
>>> 118:     public static Stream nonexistentProvider() {
>> 
>> The `nonexistentProvider` seems like an odd name. The only provider here is the junit provider (not a FileSystem provider)
>> How about `NoTempDir` and `TempDir` for the two argument streams.
>
> That definitely sounds more reasonable. Unfortunate nomenclature on my part.

I think maybe instead "tempDirSource' and "noTempDirSource."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330720489

From bpb at openjdk.org  Tue Sep 19 21:35:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 21:35:09 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v6]
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: 

> Add a `finally` block to delete the created files.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8315960: Rename MethodSources; use Stream.toList; check value returned by file deletion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15757/files
  - new: https://git.openjdk.org/jdk/pull/15757/files/cab8fa50..50411b85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=04-05

  Stats: 11 lines in 1 file changed: 2 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15757/head:pull/15757

PR: https://git.openjdk.org/jdk/pull/15757

From bpb at openjdk.org  Tue Sep 19 21:35:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 21:35:09 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v5]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
 
 
 
Message-ID: <85OfXlRiRB0bKx6mmJOF4ZqelK5Wld9VjlsYP05jmN4=.15424492-7d5b-4f11-98fc-79856421fc75@github.com>

On Tue, 19 Sep 2023 21:23:40 GMT, Brian Burkhalter  wrote:

>> That definitely sounds more reasonable. Unfortunate nomenclature on my part.
>
> I think maybe instead "tempDirSource' and "noTempDirSource."

So changed in 50411b85aeefb2576a149ae126b7d55aad6e2be0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330726991

From bpb at openjdk.org  Tue Sep 19 21:35:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 21:35:10 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v4]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
 
Message-ID: 

On Tue, 19 Sep 2023 20:55:00 GMT, Naoto Sato  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8315960: Remove vestigial unused import
>
> test/jdk/java/io/File/TempDirDoesNotExist.java line 192:
> 
>> 190:         OutputAnalyzer originalOutput = ProcessTools.executeTestJvm(options);
>> 191:         List list = originalOutput.asLines().stream().filter(line
>> 192:                 -> line.equalsIgnoreCase(WARNING)).collect(Collectors.toList());
> 
> `Stream.toList()` can be applied here

So changed in 50411b85aeefb2576a149ae126b7d55aad6e2be0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330726850

From bpb at openjdk.org  Tue Sep 19 21:45:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 21:45:13 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v7]
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: <8c90WNjRTmGoKnftU2ASACU7BPD3cx0dNNQ4P_WFfvU=.fff759d3-b933-4fef-ac34-490ff53e874e@github.com>

> Add a `finally` block to delete the created files.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8315960: Fix indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15757/files
  - new: https://git.openjdk.org/jdk/pull/15757/files/50411b85..511c511f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=05-06

  Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/15757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15757/head:pull/15757

PR: https://git.openjdk.org/jdk/pull/15757

From asemenyuk at openjdk.org  Tue Sep 19 21:46:57 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Sep 2023 21:46:57 GMT
Subject: Integrated: 8316547: Use JUnit.dir jtreg property with jpackage JUnit
 tests
In-Reply-To: 
References: 
Message-ID: 

On Tue, 19 Sep 2023 20:15:20 GMT, Alexey Semenyuk  wrote:

> Strip
> 
> /*
>  * @test
>  * @modules jdk.jpackage
>  * @compile --patch-module jdk.jpackage=${test.src} --add-reads jdk.jpackage=ALL-UNNAMED --add-exports jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED AppImageFileTest.java
>  * @run junit/othervm --patch-module jdk.jpackage=${test.classes} --add-reads jdk.jpackage=ALL-UNNAMED --add-exports jdk.jpackage/jdk.jpackage.internal=ALL-UNNAMED jdk.jpackage.internal.AppImageFileTest
>  */
> 
> comment from jpackage JUnit tests and instruct jtreg to run them through `JUnit.dirs` property.

This pull request has now been integrated.

Changeset: 25681886
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/25681886304a87053574d4e4b0d1c3eeb4f02093
Stats:     1407 lines in 19 files changed: 669 ins; 735 del; 3 mod

8316547: Use JUnit.dir jtreg property with jpackage JUnit tests

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/15826

From duke at openjdk.org  Tue Sep 19 21:47:01 2023
From: duke at openjdk.org (iaroslavski)
Date: Tue, 19 Sep 2023 21:47:01 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v39]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 01:57:44 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 two additional commits since the last revision:
> 
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments

Hi Vamsi,

The first parameter of introduced method ``sort(Class elemType, A array, long offset, int low, int high, SortOperation so)``
is ``elemType`` (int.class, long,class etc.). The third parameter is ``offset`` and it depends on ``elemType``. For example,
if ``elemType`` is int.class, offset is Unsafe.ARRAY_INT_BASE_OFFSET etc.

Can you detect offset inside intrinsic (C++ code) and remove it from Java code?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1726542858

From bpb at openjdk.org  Tue Sep 19 21:55:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 21:55:24 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java
 fails in Windows 11 [v2]
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: Make value of exceptionExpected more robust to Windows version

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15460/files
  - new: https://git.openjdk.org/jdk/pull/15460/files/5dae3470..1d18442c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15460&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15460&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 2 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 Sep 19 22:07:22 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 22:07:22 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v2]
In-Reply-To: 
References: 
Message-ID: 

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316000: Revert implementation change; modify specification to match longstanding behavior

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15673/files
  - new: https://git.openjdk.org/jdk/pull/15673/files/33a84f5c..08c5fd93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=00-01

  Stats: 115 lines in 3 files changed: 44 ins; 58 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/15673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15673/head:pull/15673

PR: https://git.openjdk.org/jdk/pull/15673

From bpb at openjdk.org  Tue Sep 19 22:08:39 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 22:08:39 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v2]
In-Reply-To: 
References: 
 
 <5nGQ3XRmhjhiYRl4Y4IvGQ1Qu24kQmfMoLdNNdOiWPc=.dc573a6c-e552-426d-bb94-e1f2a97e2a9d@github.com>
 
 
Message-ID: 

On Fri, 15 Sep 2023 14:35:43 GMT, Alan Bateman  wrote:

>> If this code does not interact with ACL-based security, then it's not clear to me that there's anything to be done here.
>
>> If this code does not interact with ACL-based security, then it's not clear to me that there's anything to be done here.
> 
> Right, these methods were created with POSIX file permissions in mind. On the surface, the only result it can return is false (to mean fail) but the concern is that it would be an incompatible change so we need to think a bit more about it.

Commit 08c5fd936e79fe1d08ca5c7fc9cc59a8c71ff555 reverts the impl changes in favor of adjusting the spec to match behavior. This PR will be tagged and a CSR created once there is consensus on the spec update.

Note that the spec of `File.setWritable` is _not_ changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15673#discussion_r1330754200

From bpb at openjdk.org  Tue Sep 19 22:48:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 22:48:20 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v3]
In-Reply-To: 
References: 
Message-ID: 

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316000: Add the API notes to the corresponding single parameter methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15673/files
  - new: https://git.openjdk.org/jdk/pull/15673/files/08c5fd93..9712535c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=01-02

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15673/head:pull/15673

PR: https://git.openjdk.org/jdk/pull/15673

From naoto at openjdk.org  Tue Sep 19 22:57:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 22:57:50 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales
Message-ID: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>

Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/15829/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15829&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316540
  Stats: 15 lines in 1 file changed: 9 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15829/head:pull/15829

PR: https://git.openjdk.org/jdk/pull/15829

From naoto at openjdk.org  Tue Sep 19 23:10:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 23:10:40 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 19 Sep 2023 21:10:18 GMT, Justin Lu  wrote:

>> src/java.base/share/classes/sun/util/calendar/CalendarUtils.java line 132:
>> 
>>> 130:      * Mimics sprintf(buf, "%0*d", decaimal, width).
>>> 131:      */
>>> 132:     public static StringBuilder sprintf0d(StringBuilder sb, int value, int width) {
>> 
>> Can this (and the following overload) method be eliminated? No need to mimic `sprintf` here, but using `String.format`/`formatted` should suffice?
>
> Thanks for reviewing, replaced the two methods with Formatter (there are occurrences in _test_ as well)

Oh, I was not aware that the utility methods were used in `Date.toString()`. I will have to take my suggestion back for performance reasons (assuming the existing implementation is faster). Sorry for not noticing that beforehand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15803#discussion_r1330789413

From liach at openjdk.org  Tue Sep 19 23:51:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Sep 2023 23:51:41 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased
In-Reply-To: 
References: 
Message-ID: 

On Thu, 7 Sep 2023 11:13:44 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.

src/java.base/share/classes/java/util/AbstractMap.java line 318:

> 316:      * and returned in response to all subsequent calls.  No synchronization
> 317:      * is performed, so there is a slight chance that multiple calls to this
> 318:      * method will not all return the same set.

The `@implSpec` above is now outdated since caching is removed.

src/java.base/share/classes/java/util/AbstractMap.java line 372:

> 370:      * returned in response to all subsequent calls.  No synchronization is
> 371:      * performed, so there is a slight chance that multiple calls to this
> 372:      * method will not all return the same collection.

Same outdated `@implSpec`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1330809911
PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1330809969

From liach at openjdk.org  Tue Sep 19 23:51:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Sep 2023 23:51:44 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased
In-Reply-To: <8fOcDAP-yNMbgd_SLIAlrYCmKwGQWvo2NeJX3CnW8n8=.753376b5-1bf1-4e25-8459-4bf138ad8b1e@github.com>
References: 
 <8fOcDAP-yNMbgd_SLIAlrYCmKwGQWvo2NeJX3CnW8n8=.753376b5-1bf1-4e25-8459-4bf138ad8b1e@github.com>
Message-ID: 

On Tue, 19 Sep 2023 18:38:06 GMT, ExE Boss  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.
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1330809662

From bpb at openjdk.org  Wed Sep 20 02:17:39 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 02:17:39 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 11 Sep 2023 16:24:32 GMT, Brian Burkhalter  wrote:

> These also fail with "Bad pathname" with the master but give the erroneous results `C:\\\foo` and `C:`, respectively, with the patch. This needs to be fixed.

The problem here might be that `File.getCanonicalPath` resolves the path

return FS.canonicalize(FS.resolve(this));

before calling `FS.canonicalize`. It could be that if after stripping the `\\\?\` prefix the result is relative or drive-relative, then it should first be resolved in the same way before proceeding.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1726779717

From liach at openjdk.org  Wed Sep 20 02:38:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Sep 2023 02:38:40 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 26 Jun 2023 14:14:54 GMT, Lance Andersen  wrote:

> @LanceAndersen This one is going to require checking that startup isn't impacted.

Now that `ByteArrayLittleEndian` is used in Integer toString, don't think this patch will affect the startup class loading sequence.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1726792433

From jwaters at openjdk.org  Wed Sep 20 03:52:41 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 20 Sep 2023 03:52:41 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 18:10:12 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
>> 
>> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
>> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
>> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
>> 
>> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
>> No new tests. Existing tier1-2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused define

Looks Great!

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15789#pullrequestreview-1634546076

From djelinski at openjdk.org  Wed Sep 20 04:40:39 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 20 Sep 2023 04:40:39 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v7]
In-Reply-To: <8c90WNjRTmGoKnftU2ASACU7BPD3cx0dNNQ4P_WFfvU=.fff759d3-b933-4fef-ac34-490ff53e874e@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 <8c90WNjRTmGoKnftU2ASACU7BPD3cx0dNNQ4P_WFfvU=.fff759d3-b933-4fef-ac34-490ff53e874e@github.com>
Message-ID: 

On Tue, 19 Sep 2023 21:45:13 GMT, Brian Burkhalter  wrote:

>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315960: Fix indentation

test/jdk/java/io/File/TempDirDoesNotExist.java line 153:

> 151:     @ParameterizedTest
> 152:     @MethodSource("tempDirSource")
> 153:     public void existingMessage(int exitValue, String errorMsg,

`exitValue` is always zero, and `errorMsg` is always `WARNING`; do you need to use parameters here?

test/jdk/java/io/File/TempDirDoesNotExist.java line 161:

> 159:     @ParameterizedTest
> 160:     @MethodSource("noTempDirSource")
> 161:     public void nonexistentMessage(int exitValue, String errorMsg,

exitValue is always zero, and errorMsg is always WARNING; do you need to use parameters here?

test/jdk/java/io/File/TempDirDoesNotExist.java line 170:

> 168:     @MethodSource("counterSource")
> 169:     public  void messageCounter(int exitValue, String... options)
> 170:         throws Exception {

Suggestion:

    public void messageCounter(int exitValue, String... options)
            throws Exception {

test/jdk/java/io/File/TempDirDoesNotExist.java line 174:

> 172:         List list = originalOutput.asLines().stream().filter(line
> 173:                 -> line.equalsIgnoreCase(WARNING)).toList();
> 174:         if (list.size() != 1 || originalOutput.getExitValue() != exitValue)

(preexisting) the exception message doesn't make much sense in the second case (`originalOutput.getExitValue() != exitValue`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330970785
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330970874
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330979437
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1330973190

From jpai at openjdk.org  Wed Sep 20 05:13:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Sep 2023 05:13:45 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales
In-Reply-To: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
Message-ID: 

On Tue, 19 Sep 2023 22:49:36 GMT, Naoto Sato  wrote:

> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.

Hello Naoto,  the use of `UTC` looks good to me. Since the failing `assertCurrentDate()` method is only called in `testEmptySysPropValue()`, should we perhaps limit this usage of `UTC` timezone to only that test?  The rest of test methods just verify that whatever value was passed to the `java.properties.date` system property was written out as a comment in the properties file and they don't assert any `Date` semantics.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15829#issuecomment-1726978731

From liach at openjdk.org  Wed Sep 20 05:48:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Sep 2023 05:48:14 GMT
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type) [v4]
In-Reply-To: 
References: 
Message-ID: <85wM8lX4sPDwPxDCREbcffoi1CE4Bn6LnFA0OApOp7c=.879a1741-077e-4133-98a3-907d85708062@github.com>

> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which should be implementation details.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html for context.
> 
> This patch moves the implementation to `DirectCodeBuilder`'s original use sites; the old `b.canWriteDirect` branch   is redundant, as `writeIndex`'s implementation already performs such an optimization.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Fix line ending, update corpus test
 - Share the local var writing logic in a helper class
 - oops, CorpusTest used this internal API
 - Remove implementation detail writeTo from LocalVariable(Type)

-------------

Changes: https://git.openjdk.org/jdk/pull/14705/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14705&range=03
  Stats: 155 lines in 8 files changed: 78 ins; 69 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14705/head:pull/14705

PR: https://git.openjdk.org/jdk/pull/14705

From pminborg at openjdk.org  Wed Sep 20 06:04:26 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 20 Sep 2023 06:04:26 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v2]
In-Reply-To: 
References: 
Message-ID: <4sfMpKR14_fw4_mN2_bBUNfgiC2XBtHie4YsUBce0-U=.371cc265-78cc-41dc-bda6-e73f01163432@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 redundant impl spec parts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15614/files
  - new: https://git.openjdk.org/jdk/pull/15614/files/f0410ee3..2cb090b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 8 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 jlu at openjdk.org  Wed Sep 20 07:00:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Sep 2023 07:00:23 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations. Drive by cleanup included.
> 
> As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).
> 
> 
> This system has the following structure,
> 
> `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
> (`Gregorian, JulianCalendar, LocalGregorianCalendar`)
> 
> `CalendarDate` extended by `BaseCalendar.Date` extended by 
> (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)
> 
> Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - cleanup CalendarDate after revert
 - Revert "Replace sprintf0d with Formatter"
   
   This reverts commit 84a346aed2be262b717f82fbbc32a4ed0323bccc.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15803/files
  - new: https://git.openjdk.org/jdk/pull/15803/files/790f7506..aaee9aa9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15803&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15803&range=03-04

  Stats: 85 lines in 7 files changed: 45 ins; 5 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/15803.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15803/head:pull/15803

PR: https://git.openjdk.org/jdk/pull/15803

From duke at openjdk.org  Wed Sep 20 07:15:04 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 20 Sep 2023 07:15:04 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v39]
In-Reply-To: 
References: 
 
 
Message-ID: <75L0ZfkEmp7GPjLYPLQX1r4TII6XZkmkSqiJPJuWK88=.137c9040-c2cb-4762-b246-445f068c509e@github.com>

On Tue, 19 Sep 2023 21:44:00 GMT, iaroslavski  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update DualPivotQuicksort.java
>>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments
>
> Hi Vamsi,
> 
> The first parameter of introduced method ``sort(Class elemType, A array, long offset, int low, int high, SortOperation so)``
> is ``elemType`` (int.class, long,class etc.). The third parameter is ``offset`` and it depends on ``elemType``. For example,
> if ``elemType`` is int.class, offset is Unsafe.ARRAY_INT_BASE_OFFSET etc.
> 
> Can you detect offset inside intrinsic (C++ code) and remove it from Java code?

> Hello Vladimir (@iaroslavski ),
> 
> Could you please file a separate PR for integrating the `ArraysSort.java` JMH benchmark?
> 
> > 2. You introduced benchmarking class test/micro/org/openjdk/bench/java/util/ArraysSort.java, that's great,
> >    but there is the same class in PR https://raw.githubusercontent.com/openjdk/jdk/42e17e45b1adc4d77ba5549770ce591d96d4b1fe/test/micro/org/openjdk/bench/java/util/ArraysSort.java
> >    which covers all types (not int/long/float/double only) and there are different data inputs (not random only).
> >    Could you please switch to the more powerful ArraysSort class?
> 
> Thanks, Vamsi

Hi Vamsi,

I'm not sure about new PR  for ArraysSort.java. Why do we need separate PR?
You can take my version of ArraysSort.java from https://github.com/openjdk/jdk/pull/13568,
no any objections from my side.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1727103206

From duke at openjdk.org  Wed Sep 20 07:21:59 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 20 Sep 2023 07:21:59 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v39]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 01:57:44 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 two additional commits since the last revision:
> 
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments

... and suggestion to improve naming: there are inconsistent new names: pivotIndices, indexPivot1 and indexPivot2.
I think names pivotIndices, pivotIndex1 and pivotIndex2 will be better. Do you agree?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1727112096

From duke at openjdk.org  Wed Sep 20 07:24:48 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 20 Sep 2023 07:24:48 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v9]
In-Reply-To: <4gJ8559jIkiqFQNZHixQ1omfMjW7kKRtjaYFc92Xb90=.b64864d7-a56e-40bd-9581-d5abf97cb7e5@github.com>
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 Fri, 15 Sep 2023 20:17:17 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.
>
>> > 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?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1727115667

From liach at openjdk.org  Wed Sep 20 07:27:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Sep 2023 07:27:42 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v2]
In-Reply-To: <4sfMpKR14_fw4_mN2_bBUNfgiC2XBtHie4YsUBce0-U=.371cc265-78cc-41dc-bda6-e73f01163432@github.com>
References: 
 <4sfMpKR14_fw4_mN2_bBUNfgiC2XBtHie4YsUBce0-U=.371cc265-78cc-41dc-bda6-e73f01163432@github.com>
Message-ID: 

On Wed, 20 Sep 2023 06:04:26 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 redundant impl spec parts

We might need a CSR for the removal of `@implSpec` and equality behavior that @ExE-Boss described.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-1727119718

From alanb at openjdk.org  Wed Sep 20 07:28:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 07:28:43 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 20 Sep 2023 02:14:48 GMT, Brian Burkhalter  wrote:

> It could be that if after stripping the `\\\?\` prefix the result is relative or drive-relative, then it should first be resolved in the same way before proceeding.

Right, which is why the one-arg WinNTFileSystem.resolve may be the right place to check for the prefix as it would fix the issue for both getAbsolutePath too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1727121877

From liach at openjdk.org  Wed Sep 20 07:35:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Sep 2023 07:35:40 GMT
Subject: RFR: 8311084: Add typeSymbol() API for applicable constant pool
 entries [v3]
In-Reply-To: 
References: 
Message-ID: 

> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or MethodTypeDesc).
> 
> This API is not added to NameAndTypeEntry itself, for a NameAndTypeEntry only knows if its type should be a field or method type from the other entries that refer to it.
> 
> This is one of the issues discussed in this mailing list thread: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into feature/cpentry-typesym
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cpentry-typesym
 - Use typeSymbol in asSymbol
 - Add typeSymbol API for a few constant pool entries

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14706/files
  - new: https://git.openjdk.org/jdk/pull/14706/files/3ae616ef..dd288733

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14706&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14706&range=01-02

  Stats: 249978 lines in 5218 files changed: 100290 ins; 97603 del; 52085 mod
  Patch: https://git.openjdk.org/jdk/pull/14706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14706/head:pull/14706

PR: https://git.openjdk.org/jdk/pull/14706

From liach at openjdk.org  Wed Sep 20 07:35:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Sep 2023 07:35:42 GMT
Subject: RFR: 8311084: Add typeSymbol() API for applicable constant pool
 entries [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 30 Jun 2023 02:42:08 GMT, Chen Liang  wrote:

>> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or MethodTypeDesc).
>> 
>> This API is not added to NameAndTypeEntry itself, for a NameAndTypeEntry only knows if its type should be a field or method type from the other entries that refer to it.
>> 
>> This is one of the issues discussed in this mailing list thread: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use typeSymbol in asSymbol

@asotona Can you review this Classfile API utility addition?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14706#issuecomment-1727129377

From anleonar at redhat.com  Wed Sep 20 07:38:22 2023
From: anleonar at redhat.com (Andrew Leonard)
Date: Wed, 20 Sep 2023 08:38:22 +0100
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
 
 <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>
Message-ID: 

Thanks Alan,

So different gcc, glibc, Xcode,.. agree, they need to be the same for
identical bits.
However, at the moment using the same toolchains, if you do a standard
product build,
and then a bootcycle build, of the same source, jrt-fs.jar will differ.
I'll do some investigation of the make files to see if a "Build JDK"
rebuild of jrt-fs.jar is
feasible.

Cheers
Andrew


On Tue, Sep 19, 2023 at 5:42?PM Alan Bateman 
wrote:

> On 18/09/2023 14:51, Andrew Leonard wrote:
> > Thanks for the clarification Alan.
> >
> > To ensure the reproducibility of the whole JDK image regardless of the
> > specific bootjdk used, would it make sense once the "Build JDK" has
> > been built, we re-build jrt-fs.jar again using the "Build JDK" ? Thus
> > jrt-fs.jar will be consistent with the rest of the image in terms of
> > what it is compiled with.
> >
>
> The boot JDK will be JDK N-1, or the newly built JDK in the case of boot
> cycle builds. It seems a bit of a stretch to have builds using different
> tool chains to produce identical bits but maybe you mean something else.
>
> In any case, for jrt-fs.jar the important thing is that they are
> compiled to --release 8 (that might rev at some points) so that
> IDEs/tools can open a target run-time image as a file system and access
> the classes/resources.
>
> -Alan.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alanb at openjdk.org  Wed Sep 20 08:26:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 08:26:42 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 22:48:20 GMT, Brian Burkhalter  wrote:

>> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316000: Add the API notes to the corresponding single parameter methods

I agree this one needs a spec clarification as changing the implementation would be an incompatible change leading to the methods apparently failing for cases where they didn't previously fail.  I don't think it will work to just add an apiNote, it needs to normative. Also the descriptions of the return value say that the method fails (which can be interpreted to mean return false) when the file system doesn't support the permission.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15673#issuecomment-1727217278

From aturbanov at openjdk.org  Wed Sep 20 08:57:44 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 20 Sep 2023 08:57:44 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted [v5]
In-Reply-To: 
References: 
 
Message-ID: <7o_avxI0jeQC5gIzke3gTzXXUVUwyoFBf7Mav2JNAII=.2aae7330-68cb-4f36-b250-d677ae613bb1@github.com>

On Wed, 20 Sep 2023 07:00:23 GMT, Justin Lu  wrote:

>> Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations. Drive by cleanup included.
>> 
>> As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).
>> 
>> 
>> This system has the following structure,
>> 
>> `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
>> (`Gregorian, JulianCalendar, LocalGregorianCalendar`)
>> 
>> `CalendarDate` extended by `BaseCalendar.Date` extended by 
>> (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)
>> 
>> Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup CalendarDate after revert
>  - Revert "Replace sprintf0d with Formatter"
>    
>    This reverts commit 84a346aed2be262b717f82fbbc32a4ed0323bccc.

src/java.base/share/classes/sun/util/calendar/CalendarDate.java line 63:

> 61:  */
> 62: public sealed abstract class CalendarDate implements Cloneable
> 63:         permits BaseCalendar.Date {

Can we just merge `CalendarDate` and `BaseCalendar.Date` to be the one class?
I think it will greatly simplify the code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15803#discussion_r1331283073

From liach at openjdk.org  Wed Sep 20 09:25:56 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Sep 2023 09:25:56 GMT
Subject: RFR: 8316587: Use ArraysSupport.vectorizedHashCode in Utf8EntryImpl
Message-ID: <3JSJ1HphYzBvczUUrmjZyhHLibVARKYgRJHv95VuiHc=.5374778f-a792-43bb-ac65-71b05d2906ab@github.com>

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

-------------

Commit messages:
 - Use JLA string utilities for utf8 entry reading

Changes: https://git.openjdk.org/jdk/pull/15837/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15837&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316587
  Stats: 47 lines in 2 files changed: 24 ins; 13 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/15837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15837/head:pull/15837

PR: https://git.openjdk.org/jdk/pull/15837

From cstein at openjdk.org  Wed Sep 20 10:24:43 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 20 Sep 2023 10:24:43 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 18:30:10 GMT, Qing Xiao  wrote:

>> Modified all tests under lib-test/jdk to use JUnit
>
> Qing Xiao has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/lib-test/jdk/test/lib/hexdump/ObjectStreamPrinterTest.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Update test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Update test/lib-test/jdk/test/lib/format/ArrayDiffTest.java
>    
>    Co-authored-by: Christian Stein 

Looks good to me.

Tested with `--test test/lib-test/jdk/test/lib`.

-------------

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15131#pullrequestreview-1635286817

From rpressler at openjdk.org  Wed Sep 20 10:48:38 2023
From: rpressler at openjdk.org (Ron Pressler)
Date: Wed, 20 Sep 2023 10:48:38 GMT
Subject: RFR: 8316456: StackWalker may skip Continuation::yield0 frame
 mistakenly
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 23:00:09 GMT, Mandy Chung  wrote:

> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
> stream is currently at the frame decoded in the last patch and so always
> advances to the next frame before filling in the new batch of stack frame.
> However `JVM_MoreStackWalk` may return 0.  The library will set 
> the continuation to its parent. It then call `JVM_MoreStackWalk` to continue
> the stack walking but the last decoded frame has already been advanced.
> The Java frame stream is already at the top frame of the parent continuation. .
> The current implementation skips "Continuation::yield0" mistakenly.  This
> only happens with `-XX:+ShowHiddenFrames` or `StackWalker.Option.SHOW_HIDDEN_FRAMES`.
> 
> The fix is to pass the number of frames decoded in the last batch to `JVM_MoreStackWalk`
> so that the VM will determine if the current frame should be skipped or not.
> 
> `test/jdk/jdk/internal/vm/Continuation/Scoped.java` test now correctly checks
> the expected result where "yield0" exists between "enter" and "run" frames.

Marked as reviewed by rpressler (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15804#pullrequestreview-1635330981

From dfuchs at openjdk.org  Wed Sep 20 11:26:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Sep 2023 11:26:46 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: 
References: 
 
 
Message-ID: <_SswosDeHNVdHm-0KVa9Pjfi65wnESObTy9RI3mVMjs=.7c401051-50b2-4777-a15d-ba2bf27eb38a@github.com>

On Tue, 19 Sep 2023 20:51:41 GMT, Tim Prinzing  wrote:

> The existing JFR tests TestSocketChannelEvents and TestSocketEvents in jdk.jfr.event.io verify the events are still emitted as expected.

Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1727528861

From alanb at openjdk.org  Wed Sep 20 11:26:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 11:26:47 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: <_SswosDeHNVdHm-0KVa9Pjfi65wnESObTy9RI3mVMjs=.7c401051-50b2-4777-a15d-ba2bf27eb38a@github.com>
References: 
 
 
 <_SswosDeHNVdHm-0KVa9Pjfi65wnESObTy9RI3mVMjs=.7c401051-50b2-4777-a15d-ba2bf27eb38a@github.com>
Message-ID: <8dq0EZ2nZuSs-fQhlpSODsL6J_5ueLLBYK4tQy3EHTo=.bb1aa2d6-a760-4857-9671-b530d0aa4883@github.com>

On Wed, 20 Sep 2023 11:21:51 GMT, Daniel Fuchs  wrote:

> Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests?

I don't think so as these tests are just used to check that changes haven't broken anything.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1727532006

From tprinzing at openjdk.org  Wed Sep 20 12:37:02 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 20 Sep 2023 12:37:02 GMT
Subject: Integrated: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: 
References: 
Message-ID: 

On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing  wrote:

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

This pull request has now been integrated.

Changeset: b275bdd9
Author:    Tim Prinzing 
Committer: Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/b275bdd9b55b567cfe60c389d5ef8b70615928f4
Stats:     906 lines in 13 files changed: 519 ins; 379 del; 8 mod

8308995: Update Network IO JFR events to be static mirror events

Reviewed-by: egahlin, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14342

From magnus.ihse.bursie at oracle.com  Wed Sep 20 13:12:01 2023
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 20 Sep 2023 15:12:01 +0200
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: 
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
 
 <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>
 
Message-ID: <9ba74ce3-2c21-4682-ba11-fb2491b76bfb@oracle.com>

On 2023-09-20 09:38, Andrew Leonard wrote:

> Thanks Alan,
>
> So different gcc, glibc, Xcode,.. agree, they need to be the same for 
> identical bits.
> However, at the moment using the same toolchains, if you do a standard 
> product build,
> and then a bootcycle build, of the same source, jrt-fs.jar will differ.
> I'll do some investigation of the make files to see if a "Build JDK" 
> rebuild of jrt-fs.jar is
> feasible.

I would not in general assume that a normal build and a bootcycle build 
produce identical results. A bootcycle build will build the product 
using a newer version of the JDK (viz. the one you just build from the 
sources), and as such, changes to javac can result in different class 
file outputs, etc. That being said, for large time periods of the JDK 
source code, a normal build and a bootcycle build can certainly result 
in the same output, since no changes have been made in the product that 
affects how .class files are generated. But that is not guaranteed, nor 
is a difference between normal and bootcycle build a sign of trouble or 
a defect.

If jrt-fs.jar is consistently different between a bootcycle build and a 
normal build, that sounds a bit odd, though. Especially since it should 
be built with `--release 8` (or something like that) to ensure it is 
usable on older Java; and that output ought not to really change as the 
JDK develops.

(Also, questions about the build process is preferably handled on the 
build-dev list)

/Magnus


>
> Cheers
> Andrew
>
>
> On Tue, Sep 19, 2023 at 5:42?PM Alan Bateman  
> wrote:
>
>     On 18/09/2023 14:51, Andrew Leonard wrote:
>     > Thanks for the clarification Alan.
>     >
>     > To ensure the reproducibility of the whole JDK image regardless
>     of the
>     > specific bootjdk used, would it make sense once the "Build JDK" has
>     > been built, we re-build jrt-fs.jar again using the "Build JDK" ?
>     Thus
>     > jrt-fs.jar will be consistent with the rest of the image in
>     terms of
>     > what it is compiled with.
>     >
>
>     The boot JDK will be JDK N-1, or the newly built JDK in the case
>     of boot
>     cycle builds. It seems a bit of a stretch to have builds using
>     different
>     tool chains to produce identical bits but maybe you mean something
>     else.
>
>     In any case, for jrt-fs.jar the important thing is that they are
>     compiled to --release 8 (that might rev at some points) so that
>     IDEs/tools can open a target run-time image as a file system and
>     access
>     the classes/resources.
>
>     -Alan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jvernee at openjdk.org  Wed Sep 20 14:45:44 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 20 Sep 2023 14:45:44 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 18:10:12 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
>> 
>> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
>> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
>> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
>> 
>> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
>> No new tests. Existing tier1-2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused define

LGTM

src/java.base/windows/native/libjava/java_props_md.c line 214:

> 212:         HRESULT hr;
> 213:         WCHAR *tmpPath = NULL;
> 214:         hr = SHGetKnownFolderPath(&FOLDERID_Profile, KF_FLAG_DONT_VERIFY, NULL, &tmpPath);

I'd say inline the variable declaration here as well
Suggestion:

        HRESULT hr = SHGetKnownFolderPath(&FOLDERID_Profile, KF_FLAG_DONT_VERIFY, NULL, &tmpPath);

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15789#pullrequestreview-1635822883
PR Review Comment: https://git.openjdk.org/jdk/pull/15789#discussion_r1331744667

From jvernee at openjdk.org  Wed Sep 20 14:45:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 20 Sep 2023 14:45:46 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 20 Sep 2023 14:41:59 GMT, Jorn Vernee  wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused define
>
> src/java.base/windows/native/libjava/java_props_md.c line 214:
> 
>> 212:         HRESULT hr;
>> 213:         WCHAR *tmpPath = NULL;
>> 214:         hr = SHGetKnownFolderPath(&FOLDERID_Profile, KF_FLAG_DONT_VERIFY, NULL, &tmpPath);
> 
> I'd say inline the variable declaration here as well
> Suggestion:
> 
>         HRESULT hr = SHGetKnownFolderPath(&FOLDERID_Profile, KF_FLAG_DONT_VERIFY, NULL, &tmpPath);

(And you will have to remove the declaration from the line above)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15789#discussion_r1331745594

From anleonar at redhat.com  Wed Sep 20 15:12:55 2023
From: anleonar at redhat.com (Andrew Leonard)
Date: Wed, 20 Sep 2023 16:12:55 +0100
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: <9ba74ce3-2c21-4682-ba11-fb2491b76bfb@oracle.com>
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
 
 <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>
 
 <9ba74ce3-2c21-4682-ba11-fb2491b76bfb@oracle.com>
Message-ID: 

Hi Magnus,

So yes, jrt-fs.jar can be different between a normal build and a bootcycle
build, which is where I sort of came in here... For example, building say
jdk-21 using a jdk-20 bootjdk, you will find that there is an extra inner
class in the standard build of jrt-fs.jar, due to the fact that the jdk-21
compiler optimized the inner class generation for enum's somewhere, such
that jdk/internal/jrtfs/JrtFileAttributeView$1.class only exists in a
jdk-20 compiled jrt-fs.jar!

I did experiment, and you can simply switch jrt-fs.jar to be
COMPILER="interim", however when it comes to the jar's construction via
"jar", it obviously uses the bootjdk "jar" command since the
"interim-compiler" is just a compiler....

In summary, I suspect this is just eluding to what the real purpose of
"bootcycle-images" is, which I think is essentially a "test", and I suspect
most vendors will either just do a standard "product-images" build, or
perform their own bootcycle by doing two builds...

Cheers
Andrew



On Wed, Sep 20, 2023 at 2:44?PM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2023-09-20 09:38, Andrew Leonard wrote:
>
> Thanks Alan,
>
> So different gcc, glibc, Xcode,.. agree, they need to be the same for
> identical bits.
> However, at the moment using the same toolchains, if you do a standard
> product build,
> and then a bootcycle build, of the same source, jrt-fs.jar will differ.
> I'll do some investigation of the make files to see if a "Build JDK"
> rebuild of jrt-fs.jar is
> feasible.
>
> I would not in general assume that a normal build and a bootcycle build
> produce identical results. A bootcycle build will build the product using a
> newer version of the JDK (viz. the one you just build from the sources),
> and as such, changes to javac can result in different class file outputs,
> etc. That being said, for large time periods of the JDK source code, a
> normal build and a bootcycle build can certainly result in the same output,
> since no changes have been made in the product that affects how .class
> files are generated. But that is not guaranteed, nor is a difference
> between normal and bootcycle build a sign of trouble or a defect.
>
> If jrt-fs.jar is consistently different between a bootcycle build and a
> normal build, that sounds a bit odd, though. Especially since it should be
> built with `--release 8` (or something like that) to ensure it is usable on
> older Java; and that output ought not to really change as the JDK develops.
>
> (Also, questions about the build process is preferably handled on the
> build-dev list)
>
> /Magnus
>
>
>
> Cheers
> Andrew
>
>
> On Tue, Sep 19, 2023 at 5:42?PM Alan Bateman 
> wrote:
>
>> On 18/09/2023 14:51, Andrew Leonard wrote:
>> > Thanks for the clarification Alan.
>> >
>> > To ensure the reproducibility of the whole JDK image regardless of the
>> > specific bootjdk used, would it make sense once the "Build JDK" has
>> > been built, we re-build jrt-fs.jar again using the "Build JDK" ? Thus
>> > jrt-fs.jar will be consistent with the rest of the image in terms of
>> > what it is compiled with.
>> >
>>
>> The boot JDK will be JDK N-1, or the newly built JDK in the case of boot
>> cycle builds. It seems a bit of a stretch to have builds using different
>> tool chains to produce identical bits but maybe you mean something else.
>>
>> In any case, for jrt-fs.jar the important thing is that they are
>> compiled to --release 8 (that might rev at some points) so that
>> IDEs/tools can open a target run-time image as a file system and access
>> the classes/resources.
>>
>> -Alan.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bpb at openjdk.org  Wed Sep 20 15:46:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 15:46:45 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v7]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 <8c90WNjRTmGoKnftU2ASACU7BPD3cx0dNNQ4P_WFfvU=.fff759d3-b933-4fef-ac34-490ff53e874e@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 04:29:00 GMT, Daniel Jeli?ski  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8315960: Fix indentation
>
> test/jdk/java/io/File/TempDirDoesNotExist.java line 153:
> 
>> 151:     @ParameterizedTest
>> 152:     @MethodSource("tempDirSource")
>> 153:     public void existingMessage(int exitValue, String errorMsg,
> 
> `exitValue` is always zero, and `errorMsg` is always `WARNING`; do you need to use parameters here?

Right. I intentionally left it that way to match the original but it should probably be changed.

> test/jdk/java/io/File/TempDirDoesNotExist.java line 161:
> 
>> 159:     @ParameterizedTest
>> 160:     @MethodSource("noTempDirSource")
>> 161:     public void nonexistentMessage(int exitValue, String errorMsg,
> 
> exitValue is always zero, and errorMsg is always WARNING; do you need to use parameters here?

Same comment as above re: line 100.

> test/jdk/java/io/File/TempDirDoesNotExist.java line 170:
> 
>> 168:     @MethodSource("counterSource")
>> 169:     public  void messageCounter(int exitValue, String... options)
>> 170:         throws Exception {
> 
> Suggestion:
> 
>     public void messageCounter(int exitValue, String... options)
>             throws Exception {

Thanks; will fix.

> test/jdk/java/io/File/TempDirDoesNotExist.java line 174:
> 
>> 172:         List list = originalOutput.asLines().stream().filter(line
>> 173:                 -> line.equalsIgnoreCase(WARNING)).toList();
>> 174:         if (list.size() != 1 || originalOutput.getExitValue() != exitValue)
> 
> (preexisting) the exception message doesn't make much sense in the second case (`originalOutput.getExitValue() != exitValue`)

Will reconsider this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1331832086
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1331832598
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1331834543
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1331833630

From naoto at openjdk.org  Wed Sep 20 16:12:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Sep 2023 16:12:36 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v2]
In-Reply-To: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
Message-ID: 

> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15829/files
  - new: https://git.openjdk.org/jdk/pull/15829/files/429b2369..30b0af53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15829&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15829&range=00-01

  Stats: 12 lines in 1 file changed: 3 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15829/head:pull/15829

PR: https://git.openjdk.org/jdk/pull/15829

From asotona at openjdk.org  Wed Sep 20 16:14:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 20 Sep 2023 16:14:46 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 18:30:10 GMT, Qing Xiao  wrote:

>> Modified all tests under lib-test/jdk to use JUnit
>
> Qing Xiao has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/lib-test/jdk/test/lib/hexdump/ObjectStreamPrinterTest.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Update test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Update test/lib-test/jdk/test/lib/format/ArrayDiffTest.java
>    
>    Co-authored-by: Christian Stein 

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15131#pullrequestreview-1636039145

From naoto at openjdk.org  Wed Sep 20 16:15:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Sep 2023 16:15:41 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v2]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 16:12:36 GMT, Naoto Sato  wrote:

>> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Thanks, Jai.
Since `assertCurrentDate()` is apart from the actual JVM invoking test method `testEmptySysPropValue()`, I thought it would be safer to use UTC in all test cases so that if someone calls `assertCurrentDate()` in other test methods, the test wouldn't break. But you are right that they are not needed in other locations right now. I removed those locations and instead added some instructions in `assertCurrentDate()` for future proof.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15829#issuecomment-1728050059

From asotona at openjdk.org  Wed Sep 20 16:16:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 20 Sep 2023 16:16:46 GMT
Subject: RFR: 8311084: Add typeSymbol() API for applicable constant pool
 entries [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 07:35:40 GMT, Chen Liang  wrote:

>> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or MethodTypeDesc).
>> 
>> This API is not added to NameAndTypeEntry itself, for a NameAndTypeEntry only knows if its type should be a field or method type from the other entries that refer to it.
>> 
>> This is one of the issues discussed in this mailing list thread: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/cpentry-typesym
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/cpentry-typesym
>  - Use typeSymbol in asSymbol
>  - Add typeSymbol API for a few constant pool entries

It looks good, thanks for the patch.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14706#pullrequestreview-1636043719

From duke at openjdk.org  Wed Sep 20 16:30:00 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 20 Sep 2023 16:30:00 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v39]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 01:57:44 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 two additional commits since the last revision:
> 
>  - Update DualPivotQuicksort.java
>  - Rename arraySort and arrayPartition Java methods to sort and partition. Cleanup some comments

Hello Vladimir, 

> The first parameter of introduced method `sort(Class elemType, A array, long offset, int low, int high, SortOperation so)` is `elemType` (int.class, long,class etc.). The third parameter is `offset` and it depends on `elemType`. 

The reason for using the `sort(Class elemType, A array, long offset,...)` API is to have a general API which can support sorting for `MemorySegment` in future. Also, a native heap backed MemorySegment will have to specify the `elemType` and `offset` which is not known in advance. 

This API was suggested to me and was already reviewed by others.

Thanks,
Vamsi

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1728072623

From duke at openjdk.org  Wed Sep 20 16:36:02 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Wed, 20 Sep 2023 16:36:02 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti
Message-ID: 

Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.

-------------

Commit messages:
 - Fix Javadoc links for Stream.mapMulti.

Changes: https://git.openjdk.org/jdk/pull/15794/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15794&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8271268
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15794/head:pull/15794

PR: https://git.openjdk.org/jdk/pull/15794

From psandoz at openjdk.org  Wed Sep 20 16:36:03 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 20 Sep 2023 16:36:03 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 18:09:57 GMT, Mourad Abbay  wrote:

> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.

Note to others. I suggested @mabbay pick up the dropped [PR](https://github.com/openjdk/jdk/pull/3909/), as a starter issue to help achieve OpenJDK author status.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15794#issuecomment-1724417397

From psandoz at openjdk.org  Wed Sep 20 16:36:42 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 20 Sep 2023 16:36:42 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v9]
In-Reply-To: <4gJ8559jIkiqFQNZHixQ1omfMjW7kKRtjaYFc92Xb90=.b64864d7-a56e-40bd-9581-d5abf97cb7e5@github.com>
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 Fri, 15 Sep 2023 20:17:17 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.
>
>> > 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1728082819

From psandoz at openjdk.org  Wed Sep 20 16:40:57 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 20 Sep 2023 16:40:57 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v39]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 20 Sep 2023 16:27:19 GMT, Srinivas Vamsi Parasa  wrote:

> This API was suggested to me and was already reviewed by others.

Confirming so, this was my suggestion. We use the _double-register_ addressing mode (as commonly applied in unsafe), thereby the intrinsic is capable of being used on and off-heap. To reduce the number of intrinsic methods we pass the element class as the first argument.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1728089648

From naoto at openjdk.org  Wed Sep 20 17:07:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Sep 2023 17:07:41 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted [v5]
In-Reply-To: <7o_avxI0jeQC5gIzke3gTzXXUVUwyoFBf7Mav2JNAII=.2aae7330-68cb-4f36-b250-d677ae613bb1@github.com>
References: 
 
 <7o_avxI0jeQC5gIzke3gTzXXUVUwyoFBf7Mav2JNAII=.2aae7330-68cb-4f36-b250-d677ae613bb1@github.com>
Message-ID: 

On Wed, 20 Sep 2023 08:54:55 GMT, Andrey Turbanov  wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - cleanup CalendarDate after revert
>>  - Revert "Replace sprintf0d with Formatter"
>>    
>>    This reverts commit 84a346aed2be262b717f82fbbc32a4ed0323bccc.
>
> src/java.base/share/classes/sun/util/calendar/CalendarDate.java line 63:
> 
>> 61:  */
>> 62: public sealed abstract class CalendarDate implements Cloneable
>> 63:         permits BaseCalendar.Date {
> 
> Can we just merge `CalendarDate` and `BaseCalendar.Date` to be the one class?
> I think it will greatly simplify the code.

`BaseCalendar` is for Gregorian based calendars, so its `Date` class also represents dates for those calendars, while `CalendarDate` is an abstract class for all calendar implementations. So I don't think merging them is the right direction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15803#discussion_r1331943059

From naoto at openjdk.org  Wed Sep 20 17:17:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Sep 2023 17:17:43 GMT
Subject: RFR: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 07:00:23 GMT, Justin Lu  wrote:

>> Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations. Drive by cleanup included.
>> 
>> As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).
>> 
>> 
>> This system has the following structure,
>> 
>> `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
>> (`Gregorian, JulianCalendar, LocalGregorianCalendar`)
>> 
>> `CalendarDate` extended by `BaseCalendar.Date` extended by 
>> (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)
>> 
>> Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup CalendarDate after revert
>  - Revert "Replace sprintf0d with Formatter"
>    
>    This reverts commit 84a346aed2be262b717f82fbbc32a4ed0323bccc.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15803#pullrequestreview-1636151330

From duke at openjdk.org  Wed Sep 20 17:19:42 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 20 Sep 2023 17:19:42 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
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 incrementally with one additional commit since the last revision:

  change variable names of indexPivot* to pivotIndex*

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/3e0b8cfc..b04cb6c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=38-39

  Stats: 49 lines in 1 file changed: 0 ins; 6 del; 43 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  Wed Sep 20 17:19:42 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 20 Sep 2023 17:19:42 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v39]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 20 Sep 2023 07:18:55 GMT, iaroslavski  wrote:

> ... and suggestion to improve naming: there are inconsistent new names: pivotIndices, indexPivot1 and indexPivot2. I think names pivotIndices, pivotIndex1 and pivotIndex2 will be better. Do you agree?

Please see the variable names updated as suggested, in the latest commit just pushed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1728138009

From coleenp at openjdk.org  Wed Sep 20 17:42:51 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 20 Sep 2023 17:42:51 GMT
Subject: RFR: 8315869: UseHeavyMonitors not used
Message-ID: 

Please review this trivial change to remove the UseHeavyMonitors develop option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) option.  Tested with tier1 locally.

-------------

Commit messages:
 - 8315869: UseHeavyMonitors not used

Changes: https://git.openjdk.org/jdk/pull/15845/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15845&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315869
  Stats: 16 lines in 4 files changed: 0 ins; 13 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15845.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15845/head:pull/15845

PR: https://git.openjdk.org/jdk/pull/15845

From naoto at openjdk.org  Wed Sep 20 17:42:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Sep 2023 17:42:55 GMT
Subject: Integrated: 8296246: Update Unicode Data Files to Version 15.1.0
In-Reply-To: 
References: 
Message-ID: 

On Wed, 13 Sep 2023 20:15:09 GMT, Naoto Sato  wrote:

> This PR is to incorporate the latest Unicode 15.1, which was released yesterday. Besides the usual character data update, an upgraded implementation of RegEx which reflects the Indic Conjunct Break specified in the latest [Unicode Annex #29 ("Unicode Text Segmentation")](https://unicode.org/reports/tr29/) is included. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 7c991cc5
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/7c991cc567bfe8cfa56774c545de689ee20f699a
Stats:     1534 lines in 22 files changed: 1303 ins; 16 del; 215 mod

8296246: Update Unicode Data Files to Version 15.1.0

Reviewed-by: erikj, joehw, srl, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/15728

From dcubed at openjdk.org  Wed Sep 20 17:52:39 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Sep 2023 17:52:39 GMT
Subject: RFR: 8315869: UseHeavyMonitors not used
In-Reply-To: 
References: 
Message-ID: <7oXophaXTK3o0solYmOlMrorslZqfK1us9imX67A7dI=.3d338baa-47b8-4373-969e-ce51df1110b6@github.com>

On Wed, 20 Sep 2023 17:36:06 GMT, Coleen Phillimore  wrote:

> Please review this trivial change to remove the UseHeavyMonitors develop option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) option.  Tested with tier1 locally.

Changes requested by dcubed (Reviewer).

src/hotspot/share/runtime/globals.hpp line 1064:

> 1062:   develop(bool, VerifyHeavyMonitors, false,                                 \
> 1063:           "Checks that no stack locking happens when using "                \
> 1064:           "-XX:LockingMode=LM_MONITOR")                                     \

s/LM_MONITOR/0/

I don't think you can specify the `LM_MONITOR` value on the actual cmd line.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15845#pullrequestreview-1636204262
PR Review Comment: https://git.openjdk.org/jdk/pull/15845#discussion_r1331988698

From coleenp at openjdk.org  Wed Sep 20 18:00:40 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 20 Sep 2023 18:00:40 GMT
Subject: RFR: 8315869: UseHeavyMonitors not used [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this trivial change to remove the UseHeavyMonitors develop option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) option.  Tested with tier1 locally.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update option comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15845/files
  - new: https://git.openjdk.org/jdk/pull/15845/files/acecf6f2..5d00c551

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15845&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15845&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15845.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15845/head:pull/15845

PR: https://git.openjdk.org/jdk/pull/15845

From bpb at openjdk.org  Wed Sep 20 18:10:17 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 18:10:17 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v3]
In-Reply-To: 
References: 
Message-ID: <-g4YNmJKQMMJr481Kq-GIWcS_5t_E8O050j0WHzcayA=.8b35fa27-390a-4230-9b61-ddb2f1476e5d@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: Move \\?\ prefix stripping to resolve(File)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15603/files
  - new: https://git.openjdk.org/jdk/pull/15603/files/d9d84b8e..a8726fbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=01-02

  Stats: 47 lines in 2 files changed: 24 ins; 14 del; 9 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 bpb at openjdk.org  Wed Sep 20 18:10:17 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 18:10:17 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v2]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <56Zwix8IwtvskHN0Ip69_RmjF_a4S53mKtvRmAUkvcI=.cd6e8298-2d9d-45de-9ac8-96a9d2c6e42c@github.com>

On Wed, 20 Sep 2023 07:26:02 GMT, Alan Bateman  wrote:

> the one-arg WinNTFileSystem.resolve may be the right place to check for the prefix

So changed in a8726fbb8a070388f2b9756ee88c746b12c18397 which also adds a couple of test cases. Perhaps some cases should be added to the `GetAbsolutePath` test as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1728207029

From dcubed at openjdk.org  Wed Sep 20 18:13:44 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Sep 2023 18:13:44 GMT
Subject: RFR: 8315869: UseHeavyMonitors not used [v2]
In-Reply-To: 
References: 
 
Message-ID: <2L5vLzPmYpUp4Ejahd-YPnzLCbl-TVSpFyq3_YchgLc=.e9e075d5-8d9a-4848-9051-61414f0ce601@github.com>

On Wed, 20 Sep 2023 18:00:40 GMT, Coleen Phillimore  wrote:

>> Please review this trivial change to remove the UseHeavyMonitors develop option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) option.  Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update option comment.

Thumbs up.

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15845#pullrequestreview-1636241551

From alanb at openjdk.org  Wed Sep 20 18:45:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 18:45:40 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v3]
In-Reply-To: <-g4YNmJKQMMJr481Kq-GIWcS_5t_E8O050j0WHzcayA=.8b35fa27-390a-4230-9b61-ddb2f1476e5d@github.com>
References: 
 <-g4YNmJKQMMJr481Kq-GIWcS_5t_E8O050j0WHzcayA=.8b35fa27-390a-4230-9b61-ddb2f1476e5d@github.com>
Message-ID: <_-kLDpUg49ShfFgcfZOLuATATnF210JRNrG8bNuOx_s=.74bd65c3-0b0b-4306-99d5-2b37204bb21f@github.com>

On Wed, 20 Sep 2023 18:10:17 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: Move \\?\ prefix stripping to resolve(File)

> So changed in [a8726fb](https://github.com/openjdk/jdk/commit/a8726fbb8a070388f2b9756ee88c746b12c18397) which also adds a couple of test cases. Perhaps some cases should be added to the `GetAbsolutePath` test as well.

Yes, I think it will need tests. The next thing is ask is the behavior of File::isAbsolute, it looks like it will return true for input like `\\\?\\foo` but it will be treated by toAbsolutePath as a relative path.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1728254382

From bpb at openjdk.org  Wed Sep 20 18:50:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 18:50:41 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v3]
In-Reply-To: <_-kLDpUg49ShfFgcfZOLuATATnF210JRNrG8bNuOx_s=.74bd65c3-0b0b-4306-99d5-2b37204bb21f@github.com>
References: 
 <-g4YNmJKQMMJr481Kq-GIWcS_5t_E8O050j0WHzcayA=.8b35fa27-390a-4230-9b61-ddb2f1476e5d@github.com>
 <_-kLDpUg49ShfFgcfZOLuATATnF210JRNrG8bNuOx_s=.74bd65c3-0b0b-4306-99d5-2b37204bb21f@github.com>
Message-ID: <48_vYJenS4aK8QEFtODUBrEwSOgaWImSTqMJpOLNWf0=.30aea900-10dd-410e-a958-2ee29093ac8b@github.com>

On Wed, 20 Sep 2023 18:42:31 GMT, Alan Bateman  wrote:

> File::isAbsolute, it looks like it will return true for input like `\\\?\\foo` but it will be treated by toAbsolutePath as a relative path.

Right on:

jshell> File f = new File("\\\?\\foo")
f ==> \?\foo

jshell> f.isAbsolute()
$2 ==> true

jshell> f.getAbsolutePath()
$3 ==> "C:\\Users\\bpb\\foo"

jshell> f.getCanonicalPath()
$4 ==> "C:\\Users\\bpb\\foo"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1728260652

From coleenp at openjdk.org  Wed Sep 20 18:50:44 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 20 Sep 2023 18:50:44 GMT
Subject: RFR: 8315869: UseHeavyMonitors not used [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 18:00:40 GMT, Coleen Phillimore  wrote:

>> Please review this trivial change to remove the UseHeavyMonitors develop option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) option.  Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update option comment.

Thanks Dan.  Do you agree that it's trivial?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15845#issuecomment-1728260950

From alanb at openjdk.org  Wed Sep 20 18:58:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 18:58:43 GMT
Subject: RFR: 8315869: UseHeavyMonitors not used [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 18:00:40 GMT, Coleen Phillimore  wrote:

>> Please review this trivial change to remove the UseHeavyMonitors develop option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) option.  Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update option comment.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15845#pullrequestreview-1636307098

From dcubed at openjdk.org  Wed Sep 20 19:04:39 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Sep 2023 19:04:39 GMT
Subject: RFR: 8315869: UseHeavyMonitors not used [v2]
In-Reply-To: 
References: 
 
Message-ID: <3eaV6hWJW6xPp-0DBTy0SPnBA0NJMBg6p5emwGIdkVU=.14f9be9f-82c6-419e-8572-606030563837@github.com>

On Wed, 20 Sep 2023 18:00:40 GMT, Coleen Phillimore  wrote:

>> Please review this trivial change to remove the UseHeavyMonitors develop option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) option.  Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update option comment.

Yes, I agree that this is a trivial fix. (Sorry I missed that earlier.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15845#issuecomment-1728278222

From alanb at openjdk.org  Wed Sep 20 19:08:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 19:08:39 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v3]
In-Reply-To: <48_vYJenS4aK8QEFtODUBrEwSOgaWImSTqMJpOLNWf0=.30aea900-10dd-410e-a958-2ee29093ac8b@github.com>
References: 
 <-g4YNmJKQMMJr481Kq-GIWcS_5t_E8O050j0WHzcayA=.8b35fa27-390a-4230-9b61-ddb2f1476e5d@github.com>
 <_-kLDpUg49ShfFgcfZOLuATATnF210JRNrG8bNuOx_s=.74bd65c3-0b0b-4306-99d5-2b37204bb21f@github.com>
 <48_vYJenS4aK8QEFtODUBrEwSOgaWImSTqMJpOLNWf0=.30aea900-10dd-410e-a958-2ee29093ac8b@github.com>
Message-ID: 

On Wed, 20 Sep 2023 18:47:33 GMT, Brian Burkhalter  wrote:

> > File::isAbsolute, it looks like it will return true for input like `\\\?\\foo` but it will be treated by toAbsolutePath as a relative path.
> 
> Right on:

Ideally the prefix would be removed at the front door, meaning when creating the File object, but it may be 20 years too late to do that change. From a compatibility perspective then limiting the it to canonicalization should be okay but it the path needs to make absolute again after stripping.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1728282600

From coleenp at openjdk.org  Wed Sep 20 19:12:50 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 20 Sep 2023 19:12:50 GMT
Subject: RFR: 8315869: UseHeavyMonitors not used [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 18:00:40 GMT, Coleen Phillimore  wrote:

>> Please review this trivial change to remove the UseHeavyMonitors develop option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) option.  Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update option comment.

Thanks Dan and Alan for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15845#issuecomment-1728285358

From coleenp at openjdk.org  Wed Sep 20 19:12:51 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 20 Sep 2023 19:12:51 GMT
Subject: Integrated: 8315869: UseHeavyMonitors not used
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 17:36:06 GMT, Coleen Phillimore  wrote:

> Please review this trivial change to remove the UseHeavyMonitors develop option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) option.  Tested with tier1 locally.

This pull request has now been integrated.

Changeset: 3301fb1e
Author:    Coleen Phillimore 
URL:       https://git.openjdk.org/jdk/commit/3301fb1e8ad11d7de01a052e0a2d6178a7579ba6
Stats:     16 lines in 4 files changed: 0 ins; 13 del; 3 mod

8315869: UseHeavyMonitors not used

Reviewed-by: dcubed, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15845

From bpb at openjdk.org  Wed Sep 20 20:22:39 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 20:22:39 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v3]
In-Reply-To: <-g4YNmJKQMMJr481Kq-GIWcS_5t_E8O050j0WHzcayA=.8b35fa27-390a-4230-9b61-ddb2f1476e5d@github.com>
References: 
 <-g4YNmJKQMMJr481Kq-GIWcS_5t_E8O050j0WHzcayA=.8b35fa27-390a-4230-9b61-ddb2f1476e5d@github.com>
Message-ID: 

On Wed, 20 Sep 2023 18:10:17 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: Move \\?\ prefix stripping to resolve(File)

It might be that the long prefix needs to be stripped local to several different methods. Will investigate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1728370663

From erik.joelsson at oracle.com  Wed Sep 20 20:34:25 2023
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 20 Sep 2023 13:34:25 -0700
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: 
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
 
 <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>
 
 <9ba74ce3-2c21-4682-ba11-fb2491b76bfb@oracle.com>
 
Message-ID: 

Hello Andrew,

The bootcycle-images target is AFAIK just a test. It's certainly not 
meant to be the authoritative way of building the JDK. Using JDK N-1 as 
bootjdk is the official way of producing a JDK of version JDK N. For 
convenience, and because it should work, we also allow JDK N. Vendors 
should definitely not be encouraged to use bootcycle builds to produce 
their JDK binaries.

Switching the compiler to interim would help with the reproducibility 
issue. I would support that change. I don't think we can reasonably do 
something about the jar tool.

/Erik

On 9/20/23 08:12, Andrew Leonard wrote:
> Hi Magnus,
>
> So yes, jrt-fs.jar can be different between a normal build and a 
> bootcycle build, which is where I sort of came in here... For example, 
> building say jdk-21 using a jdk-20 bootjdk, you will find that there 
> is an extra inner class in the standard build of jrt-fs.jar, due to 
> the fact that the jdk-21 compiler optimized the inner class generation 
> for enum's somewhere, such that 
> jdk/internal/jrtfs/JrtFileAttributeView$1.class only exists in a 
> jdk-20 compiled jrt-fs.jar!
>
> I did experiment, and you can simply switch jrt-fs.jar to be 
> COMPILER="interim", however when it comes to the jar's construction 
> via "jar", it obviously uses the bootjdk "jar" command since the 
> "interim-compiler" is just a compiler....
>
> In summary, I suspect this is just eluding to what the real purpose of 
> "bootcycle-images" is, which I think is essentially a "test", and I 
> suspect most vendors will either just do a standard "product-images" 
> build, or perform their own bootcycle by doing two builds...
>
> Cheers
> Andrew
>
>
>
> On Wed, Sep 20, 2023 at 2:44?PM Magnus Ihse Bursie 
>  wrote:
>
>     On 2023-09-20 09:38, Andrew Leonard wrote:
>
>>     Thanks Alan,
>>
>>     So different gcc, glibc, Xcode,.. agree, they need to be the same
>>     for identical bits.
>>     However, at the moment using the same toolchains, if you do a
>>     standard product build,
>>     and then a bootcycle build, of the same source, jrt-fs.jar will
>>     differ.
>>     I'll do some investigation of the make files to see if a "Build
>>     JDK" rebuild of jrt-fs.jar is
>>     feasible.
>
>     I would not in general assume that a normal build and a bootcycle
>     build produce identical results. A bootcycle build will build the
>     product using a newer version of the JDK (viz. the one you just
>     build from the sources), and as such, changes to javac can result
>     in different class file outputs, etc. That being said, for large
>     time periods of the JDK source code, a normal build and a
>     bootcycle build can certainly result in the same output, since no
>     changes have been made in the product that affects how .class
>     files are generated. But that is not guaranteed, nor is a
>     difference between normal and bootcycle build a sign of trouble or
>     a defect.
>
>     If jrt-fs.jar is consistently different between a bootcycle build
>     and a normal build, that sounds a bit odd, though. Especially
>     since it should be built with `--release 8` (or something like
>     that) to ensure it is usable on older Java; and that output ought
>     not to really change as the JDK develops.
>
>     (Also, questions about the build process is preferably handled on
>     the build-dev list)
>
>     /Magnus
>
>
>>
>>     Cheers
>>     Andrew
>>
>>
>>     On Tue, Sep 19, 2023 at 5:42?PM Alan Bateman
>>      wrote:
>>
>>         On 18/09/2023 14:51, Andrew Leonard wrote:
>>         > Thanks for the clarification Alan.
>>         >
>>         > To ensure the reproducibility of the whole JDK image
>>         regardless of the
>>         > specific bootjdk used, would it make sense once the "Build
>>         JDK" has
>>         > been built, we re-build jrt-fs.jar again using the "Build
>>         JDK" ? Thus
>>         > jrt-fs.jar will be consistent with the rest of the image in
>>         terms of
>>         > what it is compiled with.
>>         >
>>
>>         The boot JDK will be JDK N-1, or the newly built JDK in the
>>         case of boot
>>         cycle builds. It seems a bit of a stretch to have builds
>>         using different
>>         tool chains to produce identical bits but maybe you mean
>>         something else.
>>
>>         In any case, for jrt-fs.jar the important thing is that they are
>>         compiled to --release 8 (that might rev at some points) so that
>>         IDEs/tools can open a target run-time image as a file system
>>         and access
>>         the classes/resources.
>>
>>         -Alan.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Wed Sep 20 21:21:59 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 20 Sep 2023 21:21:59 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: 
References: 
 
Message-ID: <6_GwczT4jYYWgBTXnAohGKFQJCcJDmPlKafWPW1_UGQ=.55c10af5-e141-4ed9-82d1-1a80c53146a9@github.com>

On Wed, 20 Sep 2023 17:19:42 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:
> 
>   change variable names of indexPivot* to pivotIndex*

Hi Vamsi,

In this comment https://github.com/openjdk/jdk/pull/13568#issuecomment-1728082819
Paul suggested comparing of performance.

Could you please run benchmarking of the following 4 class?

[1] current implementation in JDK
[2] your AVX12 version based on [1], from this PR
[3] my new version with Radix sort for parallel case plus your AVX12 changes
     https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForParallel.java
[4] my new version with Radix sort for all cases plus your AVX12 changes
     https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForAll.java

Please use this JMH test, run on all sizes, all inputs but for int type only
(I applied AVX12 changes in my classes for int).
https://github.com/openjdk/jdk/blob/42e17e45b1adc4d77ba5549770ce591d96d4b1fe/test/micro/org/openjdk/bench/java/util/ArraysSort.java

Before we go ahead, it will be interesting to see the boost of performance of each improvements.

Many thanks,
Vladimir

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1728440839

From rriggs at openjdk.org  Wed Sep 20 21:23:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Sep 2023 21:23:44 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v7]
In-Reply-To: <8c90WNjRTmGoKnftU2ASACU7BPD3cx0dNNQ4P_WFfvU=.fff759d3-b933-4fef-ac34-490ff53e874e@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 <8c90WNjRTmGoKnftU2ASACU7BPD3cx0dNNQ4P_WFfvU=.fff759d3-b933-4fef-ac34-490ff53e874e@github.com>
Message-ID: 

On Tue, 19 Sep 2023 21:45:13 GMT, Brian Burkhalter  wrote:

>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315960: Fix indentation

test/jdk/java/io/File/TempDirDoesNotExist.java line 98:

> 96:                                       new String[] {
> 97:                                           "-Djava.io.tmpdir=" +
> 98:                                           tempDir(),

These lines could be joined. Or perhaps move the "+" to the beginning of the next line as in the others below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1332196855

From duke at openjdk.org  Wed Sep 20 21:25:41 2023
From: duke at openjdk.org (iaroslavski)
Date: Wed, 20 Sep 2023 21:25:41 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:

> 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.

In this comment https://github.com/openjdk/jdk/pull/14227#issuecomment-1728440839
I asked Vamsi to compare current version in JDK (base), base + AVX512, Radix sort for all cases + AVX512, Radix sort for parallel case + AVX512.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1728444843

From bpb at openjdk.org  Wed Sep 20 21:51:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 21:51:19 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v8]
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: 

> Add a `finally` block to delete the created files.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8315960: Address additional reviewer comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15757/files
  - new: https://git.openjdk.org/jdk/pull/15757/files/511c511f..b3ac8c7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=06-07

  Stats: 64 lines in 1 file changed: 4 ins; 31 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/15757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15757/head:pull/15757

PR: https://git.openjdk.org/jdk/pull/15757

From bpb at openjdk.org  Wed Sep 20 21:51:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 21:51:19 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v7]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 <8c90WNjRTmGoKnftU2ASACU7BPD3cx0dNNQ4P_WFfvU=.fff759d3-b933-4fef-ac34-490ff53e874e@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 21:18:43 GMT, Roger Riggs  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8315960: Fix indentation
>
> test/jdk/java/io/File/TempDirDoesNotExist.java line 98:
> 
>> 96:                                       new String[] {
>> 97:                                           "-Djava.io.tmpdir=" +
>> 98:                                           tempDir(),
> 
> These lines could be joined. Or perhaps move the "+" to the beginning of the next line as in the others below.

Fixed in b3ac8c7b1242281bda86f7dc98efccf2bcefc7f6.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1332216006

From bpb at openjdk.org  Wed Sep 20 21:51:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 21:51:20 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v7]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 <8c90WNjRTmGoKnftU2ASACU7BPD3cx0dNNQ4P_WFfvU=.fff759d3-b933-4fef-ac34-490ff53e874e@github.com>
 
 
Message-ID: 

On Wed, 20 Sep 2023 15:42:27 GMT, Brian Burkhalter  wrote:

>> test/jdk/java/io/File/TempDirDoesNotExist.java line 153:
>> 
>>> 151:     @ParameterizedTest
>>> 152:     @MethodSource("tempDirSource")
>>> 153:     public void existingMessage(int exitValue, String errorMsg,
>> 
>> `exitValue` is always zero, and `errorMsg` is always `WARNING`; do you need to use parameters here?
>
> Right. I intentionally left it that way to match the original but it should probably be changed.

Extraneous parameters removed in b3ac8c7b1242281bda86f7dc98efccf2bcefc7f6.

>> test/jdk/java/io/File/TempDirDoesNotExist.java line 161:
>> 
>>> 159:     @ParameterizedTest
>>> 160:     @MethodSource("noTempDirSource")
>>> 161:     public void nonexistentMessage(int exitValue, String errorMsg,
>> 
>> exitValue is always zero, and errorMsg is always WARNING; do you need to use parameters here?
>
> Same comment as above re: line 100.

Extraneous parameters removed in b3ac8c7b1242281bda86f7dc98efccf2bcefc7f6.

>> test/jdk/java/io/File/TempDirDoesNotExist.java line 170:
>> 
>>> 168:     @MethodSource("counterSource")
>>> 169:     public  void messageCounter(int exitValue, String... options)
>>> 170:         throws Exception {
>> 
>> Suggestion:
>> 
>>     public void messageCounter(int exitValue, String... options)
>>             throws Exception {
>
> Thanks; will fix.

Fixed in b3ac8c7b1242281bda86f7dc98efccf2bcefc7f6.

>> test/jdk/java/io/File/TempDirDoesNotExist.java line 174:
>> 
>>> 172:         List list = originalOutput.asLines().stream().filter(line
>>> 173:                 -> line.equalsIgnoreCase(WARNING)).toList();
>>> 174:         if (list.size() != 1 || originalOutput.getExitValue() != exitValue)
>> 
>> (preexisting) the exception message doesn't make much sense in the second case (`originalOutput.getExitValue() != exitValue`)
>
> Will reconsider this.

Improved in b3ac8c7b1242281bda86f7dc98efccf2bcefc7f6.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1332215332
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1332215487
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1332215855
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1332215701

From joehw at openjdk.org  Wed Sep 20 21:53:44 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 20 Sep 2023 21:53:44 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v2]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 16:12:36 GMT, Naoto Sato  wrote:

>> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15829#pullrequestreview-1636561895

From jlu at openjdk.org  Wed Sep 20 22:18:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Sep 2023 22:18:08 GMT
Subject: RFR: JDK-8316629: j.text.DateFormatSymbols setZoneStrings() exception
 is unhelpful
Message-ID: 

Please review this PR, which updates the exception message for java.text.DateFormatSymbols.setZoneStrings

`setZoneStrings()` takes a multi dimensional array as input. If any row does not have a length of at least 5, an _IllegalArgumentException_ is thrown. The exception should indicate why it was thrown.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/15849/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15849&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316629
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15849.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15849/head:pull/15849

PR: https://git.openjdk.org/jdk/pull/15849

From duke at openjdk.org  Wed Sep 20 22:48:57 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 20 Sep 2023 22:48:57 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: 
References: 
 
Message-ID: <_2qUA--cT_YHORPN6SdGAswZpG_arpMkc6XxkrKIvdo=.8ec1cfaf-e253-4f04-88b5-8fc122e9342d@github.com>

On Wed, 20 Sep 2023 17:19:42 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:
> 
>   change variable names of indexPivot* to pivotIndex*

Hi Vladimir,

Sure, will run the benchmarks and post the JMH performance data.
Just trying to understand: is there a reason to use `DualPivotQuicksort_RadixForParallel.java` and `DualPivotQuicksort_RadixForAll.java`?

Would it not be sufficient to do the following two runs:

1. Baseline (Stock JDK) vs. AVX512 sort for` sort() `and `parallelSort()` ?
2. AVX512 sort vs. Radix sort for `sort()` and `parallelSort(`) ?

> [1] current implementation in JDK [2] your AVX12 version based on [1], from this PR [3] my new version with Radix sort for parallel case plus your AVX12 changes [4] my new version with Radix sort for all cases plus your AVX12 changes 

Thanks,
Vamsi

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1728520628

From naoto at openjdk.org  Wed Sep 20 23:08:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Sep 2023 23:08:40 GMT
Subject: RFR: JDK-8316629: j.text.DateFormatSymbols setZoneStrings()
 exception is unhelpful
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 22:10:16 GMT, Justin Lu  wrote:

> Please review this PR, which updates the exception message for java.text.DateFormatSymbols.setZoneStrings
> 
> `setZoneStrings()` takes a multi dimensional array as input. If any row does not have a length of at least 5, an _IllegalArgumentException_ is thrown. The exception should indicate why it was thrown.

Initially, I thought `%d` would fit here since `i` is an `int`, but would be a bit odd if the localized number were inserted in the English exception message. So `%s` which simply calls `toString()` is fine to me.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15849#pullrequestreview-1636620860

From bpb at openjdk.org  Wed Sep 20 23:11:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 23:11:27 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v4]
In-Reply-To: 
References: 
Message-ID: 

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316000: Move apiNotes to normative text; update @return descriptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15673/files
  - new: https://git.openjdk.org/jdk/pull/15673/files/9712535c..8640decd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=02-03

  Stats: 23 lines in 1 file changed: 0 ins; 4 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/15673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15673/head:pull/15673

PR: https://git.openjdk.org/jdk/pull/15673

From jlu at openjdk.org  Wed Sep 20 23:27:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Sep 2023 23:27:51 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit
Message-ID: 

Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 

Any files named BugXXXXXXX.java will be renamed after review.

-------------

Commit messages:
 - Separate data generation and data testing in BuddhistCalendarTest
 - init

Changes: https://git.openjdk.org/jdk/pull/15853/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316559
  Stats: 679 lines in 10 files changed: 206 ins; 224 del; 249 mod
  Patch: https://git.openjdk.org/jdk/pull/15853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15853/head:pull/15853

PR: https://git.openjdk.org/jdk/pull/15853

From jlu at openjdk.org  Wed Sep 20 23:32:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Sep 2023 23:32:38 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v2]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 16:12:36 GMT, Naoto Sato  wrote:

>> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15829#pullrequestreview-1636650667

From sviswanathan at openjdk.org  Wed Sep 20 23:36:57 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 20 Sep 2023 23:36:57 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 17:19:42 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:
> 
>   change variable names of indexPivot* to pivotIndex*

> Hi Vamsi,
> 
> In this comment [#13568 (comment)](https://github.com/openjdk/jdk/pull/13568#issuecomment-1728082819) Paul suggested comparing of performance.
> 
> Could you please run benchmarking of the following 4 class?
> 
> [1] current implementation in JDK [2] your AVX12 version based on [1], from this PR [3] my new version with Radix sort for parallel case plus your AVX12 changes https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForParallel.java [4] my new version with Radix sort for all cases plus your AVX12 changes https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForAll.java
> 
> Please use this JMH test, run on
> 
> * all sizes
> * all inputs
> * but for int type only (I applied AVX12 changes in my classes for int)
> * for sequential and parallel sorting (sort() and parallelSort())
> 
> https://github.com/openjdk/jdk/blob/42e17e45b1adc4d77ba5549770ce591d96d4b1fe/test/micro/org/openjdk/bench/java/util/ArraysSort.java
> 
> Before we go ahead, it will be interesting to see the boost of performance of each improvements.
> 
> Many thanks, Vladimir

>From what we (Vamsi and I) see, the two PRs are totally independent. This PR has its own merit which we have shown through various performance runs by now. This PR doesn't conflict with the radix sort PR. The perf runs that you ask for above make sense in the radix sort PR discussion and not here. There also the onus is on the author of the PR to show the merit of their work through perf runs and such.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1728555043

From bpb at openjdk.org  Wed Sep 20 23:48:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 23:48:13 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v4]
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: Move prefix stripping to separate method; add to isAbsolute

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15603/files
  - new: https://git.openjdk.org/jdk/pull/15603/files/a8726fbb..2ea422c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=02-03

  Stats: 42 lines in 1 file changed: 31 ins; 7 del; 4 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 mseledtsov at openjdk.org  Thu Sep 21 00:05:51 2023
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 21 Sep 2023 00:05:51 GMT
Subject: Withdrawn: 8313718: make container at requires command configurable
In-Reply-To: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
References: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
Message-ID: 

On Tue, 29 Aug 2023 22:01:22 GMT, Mikhailo Seledtsov  wrote:

> Container ecosystem is growing. It would be beneficial to define custom command to figure out whether a specific test host or environment allows for container testing. This enhancement seeks to make the command used by jtreg "requires" extension configurable, specifically test/jtreg-ext/requires/VMProps.java checkContainerSupport().

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15475

From bpb at openjdk.org  Thu Sep 21 00:49:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Sep 2023 00:49:52 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 23:48:13 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: Move prefix stripping to separate method; add to isAbsolute

Support for `isAbsolute` was added. All `jdk_core` tests still pass. Test cases still need to be added to `GetAbsolutePath.java` and `IsAbsolute.java`. These tests also appear ripe for conversion to JUnit 5.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1728602641

From jpai at openjdk.org  Thu Sep 21 01:31:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Sep 2023 01:31:45 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v2]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 16:12:36 GMT, Naoto Sato  wrote:

>> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Thank you Naoto for the update. This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15829#pullrequestreview-1636736028

From liach at openjdk.org  Thu Sep 21 02:38:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 02:38:08 GMT
Subject: RFR: 8316587: Use ArraysSupport.vectorizedHashCode in
 Utf8EntryImpl [v2]
In-Reply-To: <3JSJ1HphYzBvczUUrmjZyhHLibVARKYgRJHv95VuiHc=.5374778f-a792-43bb-ac65-71b05d2906ab@github.com>
References: <3JSJ1HphYzBvczUUrmjZyhHLibVARKYgRJHv95VuiHc=.5374778f-a792-43bb-ac65-71b05d2906ab@github.com>
Message-ID: 

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15837/files
  - new: https://git.openjdk.org/jdk/pull/15837/files/d0ce1181..6f5e3d72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15837&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15837&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15837/head:pull/15837

PR: https://git.openjdk.org/jdk/pull/15837

From pchilanomate at openjdk.org  Thu Sep 21 05:18:41 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 21 Sep 2023 05:18:41 GMT
Subject: RFR: 8316456: StackWalker may skip Continuation::yield0 frame
 mistakenly
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 23:00:09 GMT, Mandy Chung  wrote:

> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
> stream is currently at the frame decoded in the last patch and so always
> advances to the next frame before filling in the new batch of stack frame.
> However `JVM_MoreStackWalk` may return 0.  The library will set 
> the continuation to its parent. It then call `JVM_MoreStackWalk` to continue
> the stack walking but the last decoded frame has already been advanced.
> The Java frame stream is already at the top frame of the parent continuation. .
> The current implementation skips "Continuation::yield0" mistakenly.  This
> only happens with `-XX:+ShowHiddenFrames` or `StackWalker.Option.SHOW_HIDDEN_FRAMES`.
> 
> The fix is to pass the number of frames decoded in the last batch to `JVM_MoreStackWalk`
> so that the VM will determine if the current frame should be skipped or not.
> 
> `test/jdk/jdk/internal/vm/Continuation/Scoped.java` test now correctly checks
> the expected result where "yield0" exists between "enter" and "run" frames.

src/java.base/share/classes/java/lang/StackStreamFactory.java line 443:

> 441: 
> 442:             // If the last batch didn't fetch any frames, keep the current batch size.
> 443:             int lastBatchFrameCount = frameBuffer.numFrames();

I run some tests to understand the issue and I got the same failure if I now set MIN_BATCH_SIZE to 7. This just forces the same situation where Continuation::enter is the last frame in the buffer, otherwise since the patch also changes the batch sizes we don't fall into that issue anymore. The problem is with this numFrames() method which still returns a number > 0 after the fetch attempt that returns with no frames. Maybe there is a reset missing for origin and fence when fetching the next batch?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15804#discussion_r1332471224

From djelinski at openjdk.org  Thu Sep 21 05:30:40 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 21 Sep 2023 05:30:40 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v8]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 21:51:19 GMT, Brian Burkhalter  wrote:

>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315960: Address additional reviewer comments

Now that we're using junit, we can start using assertions

test/jdk/java/io/File/TempDirDoesNotExist.java line 142:

> 140:         OutputAnalyzer originalOutput = ProcessTools.executeTestJvm(options);
> 141:         List list = originalOutput.asLines().stream().filter(line
> 142:                 -> line.equalsIgnoreCase(WARNING)).toList();

You could use `count` instead of `toList`; the actual list is never used in this test

test/jdk/java/io/File/TempDirDoesNotExist.java line 143:

> 141:         List list = originalOutput.asLines().stream().filter(line
> 142:                 -> line.equalsIgnoreCase(WARNING)).toList();
> 143:         if (list.size() != 1)

Use assertEquals

test/jdk/java/io/File/TempDirDoesNotExist.java line 148:

> 146:                                        originalOutput.asLines().toString());
> 147:         int exitValue = originalOutput.getExitValue();
> 148:         if (exitValue != 0)

Use assertEquals

-------------

PR Review: https://git.openjdk.org/jdk/pull/15757#pullrequestreview-1636914632
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1332479846
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1332474537
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1332474679

From jbhateja at openjdk.org  Thu Sep 21 05:31:56 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 21 Sep 2023 05:31:56 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: <_2qUA--cT_YHORPN6SdGAswZpG_arpMkc6XxkrKIvdo=.8ec1cfaf-e253-4f04-88b5-8fc122e9342d@github.com>
References: 
 
 <_2qUA--cT_YHORPN6SdGAswZpG_arpMkc6XxkrKIvdo=.8ec1cfaf-e253-4f04-88b5-8fc122e9342d@github.com>
Message-ID: 

On Wed, 20 Sep 2023 22:46:16 GMT, Srinivas Vamsi Parasa  wrote:

> Hi Vladimir,
> 
> Just trying to understand: is there a reason to use `DualPivotQuicksort_RadixForParallel.java` and `DualPivotQuicksort_RadixForAll.java`?
> 
> Would it not be sufficient to do the following two runs:
> 
> 1. Baseline (Stock JDK) vs. AVX512 sort for`sort()`and `parallelSort()` ?
> 2. AVX512 sort vs. Radix sort for `sort()` and `parallelSort()` ?
> 
> > [1] current implementation in JDK [2] your AVX12 version based on [1], from this PR [3] my new version with Radix sort for parallel case plus your AVX12 changes [4] my new version with Radix sort for all cases plus your AVX12 changes
> 
> Thanks, Vamsi

Hi @vamsi-parasa , Please also add C1 intrinsification support for newly carved sort / partition intrinsics in your follow up PR https://bugs.openjdk.org/browse/JDK-8315382 , it may further improve the overall runtime for large sized array sort in tiered compilation mode.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1728877814

From liach at openjdk.org  Thu Sep 21 05:51:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 05:51:15 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the base
 class
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.

-------------

Commit messages:
 - Clean up VarHandle template classes

Changes: https://git.openjdk.org/jdk/pull/15854/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316641
  Stats: 136 lines in 5 files changed: 31 ins; 50 del; 55 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 djelinski at openjdk.org  Thu Sep 21 06:08:27 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 21 Sep 2023 06:08:27 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
> 
> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
> 
> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
> No new tests. Existing tier1-2 tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Inline variable declaration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15789/files
  - new: https://git.openjdk.org/jdk/pull/15789/files/1fa01288..3f37efa5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15789&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15789&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15789/head:pull/15789

PR: https://git.openjdk.org/jdk/pull/15789

From liach at openjdk.org  Thu Sep 21 06:27:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 06:27:40 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 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

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15698#pullrequestreview-1637003856

From xqoasis at openjdk.org  Thu Sep 21 06:27:49 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Thu, 21 Sep 2023 06:27:49 GMT
Subject: Integrated: 8313612: Use JUnit in lib-test/jdk tests
In-Reply-To: 
References: 
Message-ID: 

On Wed, 2 Aug 2023 23:25:13 GMT, Qing Xiao  wrote:

> Modified all tests under lib-test/jdk to use JUnit

This pull request has now been integrated.

Changeset: a35e96a3
Author:    Qing Xiao 
Committer: Christian Stein 
URL:       https://git.openjdk.org/jdk/commit/a35e96a3fae8722eea1d266beab22556c784241d
Stats:     301 lines in 5 files changed: 45 ins; 28 del; 228 mod

8313612: Use JUnit in lib-test/jdk tests

Reviewed-by: cstein, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/15131

From liach at openjdk.org  Thu Sep 21 06:40:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 06:40:43 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

Should I wait for Classfile API transition to preview before I come back to this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1728941810

From alanb at openjdk.org  Thu Sep 21 07:20:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Sep 2023 07:20:44 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v2]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
Message-ID: 

On Wed, 20 Sep 2023 16:12:36 GMT, Naoto Sato  wrote:

>> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

test/jdk/java/util/Properties/StoreReproducibilityTest.java line 137:

> 135:             final Path tmpFile = Files.createTempFile("8231640", ".props");
> 136:             storedFiles.add(tmpFile);
> 137:             final ProcessBuilder processBuilder = ProcessTools.createJavaProcessBuilder(

ProcessTools.createJavaProcessBuilder came up in another PR because it doesn't prepend the VM and java opts. As all usages of PB are being updated in this test then it makes me wonder if it should be changed to use createTestJvm while you're there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15829#discussion_r1332585761

From duke at openjdk.org  Thu Sep 21 07:22:59 2023
From: duke at openjdk.org (iaroslavski)
Date: Thu, 21 Sep 2023 07:22:59 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: <_2qUA--cT_YHORPN6SdGAswZpG_arpMkc6XxkrKIvdo=.8ec1cfaf-e253-4f04-88b5-8fc122e9342d@github.com>
References: 
 
 <_2qUA--cT_YHORPN6SdGAswZpG_arpMkc6XxkrKIvdo=.8ec1cfaf-e253-4f04-88b5-8fc122e9342d@github.com>
Message-ID: <4_fVDA_x_0TRl4bVrHOzAdCMQULbSQOr0qB6q20gwDM=.768a44b9-4f3e-4d34-8cd0-fb6cbfb681fc@github.com>

On Wed, 20 Sep 2023 22:46:16 GMT, Srinivas Vamsi Parasa  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change variable names of indexPivot* to pivotIndex*
>
> Hi Vladimir,
> 
> Just trying to understand: is there a reason to use `DualPivotQuicksort_RadixForParallel.java` and `DualPivotQuicksort_RadixForAll.java`?
> 
> Would it not be sufficient to do the following two runs:
> 
> 1. Baseline (Stock JDK) vs. AVX512 sort for` sort() `and `parallelSort()` ?
> 2. AVX512 sort vs. Radix sort for `sort()` and `parallelSort()` ?
> 
>> [1] current implementation in JDK [2] your AVX12 version based on [1], from this PR [3] my new version with Radix sort for parallel case plus your AVX12 changes [4] my new version with Radix sort for all cases plus your AVX12 changes 
> 
> Thanks,
> Vamsi

Hi @vamsi-parasa , @sviswa7 and @jatin-bhateja !

I agree with you that bot PRs are independent and radix sort discussion should not be here, my fault. I asked to run benchmarking because actual AVX512 changes are in C++ code and I don't have ready environment for testing.
I'm moving this discussion to PR https://github.com/openjdk/jdk/pull/13568.

Many thanks,
Vladimir

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1728996248

From alanb at openjdk.org  Thu Sep 21 07:25:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Sep 2023 07:25:41 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 21 Sep 2023 00:46:45 GMT, Brian Burkhalter  wrote:

> Support for `isAbsolute` was added. 

Okay, this looks better but I'm still concerned about other potential inconsistencies. Can you try out getParent with different input to see if any issues come up related to the prefix length.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1728999549

From djelinski at openjdk.org  Thu Sep 21 07:46:44 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 21 Sep 2023 07:46:44 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 20 Sep 2023 14:42:40 GMT, Jorn Vernee  wrote:

>> src/java.base/windows/native/libjava/java_props_md.c line 214:
>> 
>>> 212:         HRESULT hr;
>>> 213:         WCHAR *tmpPath = NULL;
>>> 214:         hr = SHGetKnownFolderPath(&FOLDERID_Profile, KF_FLAG_DONT_VERIFY, NULL, &tmpPath);
>> 
>> I'd say inline the variable declaration here as well
>> Suggestion:
>> 
>>         HRESULT hr = SHGetKnownFolderPath(&FOLDERID_Profile, KF_FLAG_DONT_VERIFY, NULL, &tmpPath);
>
> (And you will have to remove the declaration from the line above)

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15789#discussion_r1332620350

From duke at openjdk.org  Thu Sep 21 07:46:44 2023
From: duke at openjdk.org (iaroslavski)
Date: Thu, 21 Sep 2023 07:46:44 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>
 
Message-ID: 

On Wed, 30 Aug 2023 10:55:48 GMT, Laurent Bourg?s  wrote:

>> * 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:
> 
>   updated comments (v23.08)

> Hi Vladimir,
> 
> Just trying to understand: is there a reason to use `DualPivotQuicksort_RadixForParallel.java` and `DualPivotQuicksort_RadixForAll.java`?
> 
> Would it not be sufficient to do the following two runs:
> 
> 1. Baseline (Stock JDK) vs. AVX512 sort for`sort()`and `parallelSort()` ?
> 2. AVX512 sort vs. Radix sort for `sort()` and `parallelSort()` ?
> 
> Thanks, Vamsi

Hi Vamsi (@vamsi-parasa)!

I appreciate if you kindly agree to help with perf runs on your environment.
Results from your runs will help us to detect the impact of Radix sort in *vectorized* sorting, this is very important topic.

Interesting comparisons are:

1. AVX512 sort (your implementation) vs. DualPivotQuicksort_RadixForParallel (contains AVX512 + radix for parallel sort)
    https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForParallel.java

2. AVX512 sort (your implementation) vs. DualPivotQuicksort_RadixForAll (contains AVX512 + radix for all)
    https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForAll.java

If you add the 3-rd comparison
baseline (stock JDK) vs. AVX512 sort - it would be great also!

Please use this JMH test to run on:

* all sizes
* all inputs
* int type only
* sort() and parallelSort()

https://github.com/openjdk/jdk/blob/42e17e45b1adc4d77ba5549770ce591d96d4b1fe/test/micro/org/openjdk/bench/java/util/ArraysSort.java

Looking forward the results,
Vladimir

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1729029938

From anleonar at redhat.com  Thu Sep 21 08:04:31 2023
From: anleonar at redhat.com (Andrew Leonard)
Date: Thu, 21 Sep 2023 09:04:31 +0100
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: 
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
 
 <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>
 
 <9ba74ce3-2c21-4682-ba11-fb2491b76bfb@oracle.com>
 
 
Message-ID: 

Hi Erik,

Thank you for the feedback. Yes, I think I agree with you, changing the
compilation to "interim" would resolve the reproducibility, and also would
be beneficial from the "secure dev" perspective having the classes built
with the "latest&greatest" compiler. I will create a bug & PR, and perform
some testing.

Cheers
Andrew


On Wed, Sep 20, 2023 at 10:50?PM  wrote:

> Hello Andrew,
>
> The bootcycle-images target is AFAIK just a test. It's certainly not meant
> to be the authoritative way of building the JDK. Using JDK N-1 as bootjdk
> is the official way of producing a JDK of version JDK N. For convenience,
> and because it should work, we also allow JDK N. Vendors should definitely
> not be encouraged to use bootcycle builds to produce their JDK binaries.
>
> Switching the compiler to interim would help with the reproducibility
> issue. I would support that change. I don't think we can reasonably do
> something about the jar tool.
>
> /Erik
> On 9/20/23 08:12, Andrew Leonard wrote:
>
> Hi Magnus,
>
> So yes, jrt-fs.jar can be different between a normal build and a bootcycle
> build, which is where I sort of came in here... For example, building say
> jdk-21 using a jdk-20 bootjdk, you will find that there is an extra inner
> class in the standard build of jrt-fs.jar, due to the fact that the jdk-21
> compiler optimized the inner class generation for enum's somewhere, such
> that jdk/internal/jrtfs/JrtFileAttributeView$1.class only exists in a
> jdk-20 compiled jrt-fs.jar!
>
> I did experiment, and you can simply switch jrt-fs.jar to be
> COMPILER="interim", however when it comes to the jar's construction via
> "jar", it obviously uses the bootjdk "jar" command since the
> "interim-compiler" is just a compiler....
>
> In summary, I suspect this is just eluding to what the real purpose of
> "bootcycle-images" is, which I think is essentially a "test", and I suspect
> most vendors will either just do a standard "product-images" build, or
> perform their own bootcycle by doing two builds...
>
> Cheers
> Andrew
>
>
>
> On Wed, Sep 20, 2023 at 2:44?PM Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
>> On 2023-09-20 09:38, Andrew Leonard wrote:
>>
>> Thanks Alan,
>>
>> So different gcc, glibc, Xcode,.. agree, they need to be the same for
>> identical bits.
>> However, at the moment using the same toolchains, if you do a standard
>> product build,
>> and then a bootcycle build, of the same source, jrt-fs.jar will differ.
>> I'll do some investigation of the make files to see if a "Build JDK"
>> rebuild of jrt-fs.jar is
>> feasible.
>>
>> I would not in general assume that a normal build and a bootcycle build
>> produce identical results. A bootcycle build will build the product using a
>> newer version of the JDK (viz. the one you just build from the sources),
>> and as such, changes to javac can result in different class file outputs,
>> etc. That being said, for large time periods of the JDK source code, a
>> normal build and a bootcycle build can certainly result in the same output,
>> since no changes have been made in the product that affects how .class
>> files are generated. But that is not guaranteed, nor is a difference
>> between normal and bootcycle build a sign of trouble or a defect.
>>
>> If jrt-fs.jar is consistently different between a bootcycle build and a
>> normal build, that sounds a bit odd, though. Especially since it should be
>> built with `--release 8` (or something like that) to ensure it is usable on
>> older Java; and that output ought not to really change as the JDK develops.
>>
>> (Also, questions about the build process is preferably handled on the
>> build-dev list)
>>
>> /Magnus
>>
>>
>>
>> Cheers
>> Andrew
>>
>>
>> On Tue, Sep 19, 2023 at 5:42?PM Alan Bateman 
>> wrote:
>>
>>> On 18/09/2023 14:51, Andrew Leonard wrote:
>>> > Thanks for the clarification Alan.
>>> >
>>> > To ensure the reproducibility of the whole JDK image regardless of the
>>> > specific bootjdk used, would it make sense once the "Build JDK" has
>>> > been built, we re-build jrt-fs.jar again using the "Build JDK" ? Thus
>>> > jrt-fs.jar will be consistent with the rest of the image in terms of
>>> > what it is compiled with.
>>> >
>>>
>>> The boot JDK will be JDK N-1, or the newly built JDK in the case of boot
>>> cycle builds. It seems a bit of a stretch to have builds using different
>>> tool chains to produce identical bits but maybe you mean something else.
>>>
>>> In any case, for jrt-fs.jar the important thing is that they are
>>> compiled to --release 8 (that might rev at some points) so that
>>> IDEs/tools can open a target run-time image as a file system and access
>>> the classes/resources.
>>>
>>> -Alan.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liach at openjdk.org  Thu Sep 21 08:07:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 08:07:50 GMT
Subject: Integrated: 8311084: Add typeSymbol() API for applicable constant pool
 entries
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 Jun 2023 09:59:30 GMT, Chen Liang  wrote:

> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or MethodTypeDesc).
> 
> This API is not added to NameAndTypeEntry itself, for a NameAndTypeEntry only knows if its type should be a field or method type from the other entries that refer to it.
> 
> This is one of the issues discussed in this mailing list thread: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html

This pull request has now been integrated.

Changeset: 1749ba26
Author:    Chen Liang 
Committer: Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/1749ba265b5761dbe2d9d77dac559984b179adf9
Stats:     48 lines in 7 files changed: 44 ins; 0 del; 4 mod

8311084: Add typeSymbol() API for applicable constant pool entries

Reviewed-by: briangoetz, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/14706

From alanb at openjdk.org  Thu Sep 21 08:34:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Sep 2023 08:34:39 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 23:11:27 GMT, Brian Burkhalter  wrote:

>> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316000: Move apiNotes to normative text; update @return descriptions

src/java.base/share/classes/java/io/File.java line 1643:

> 1641:      *          change the access permissions of this abstract pathname.  If
> 1642:      *          the underlying file system does not implement a read permission,
> 1643:      *          then the operation will return the value of the {@code readable}

There's a switcharoo here. The method description speaks of the platform not supporting file permissions. The return description changes terminology and speaks of the file system not implementating permissions. I think we'll get these consistent but overall the intent is okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15673#discussion_r1332685101

From liach at openjdk.org  Thu Sep 21 08:50:00 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 08:50:00 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v2]
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 incrementally with one additional commit since the last revision:

  byte array var handles can share a common base class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15854/files
  - new: https://git.openjdk.org/jdk/pull/15854/files/3a73e9ad..12404165

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=00-01

  Stats: 74 lines in 4 files changed: 32 ins; 34 del; 8 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 anleonar at redhat.com  Thu Sep 21 08:59:54 2023
From: anleonar at redhat.com (Andrew Leonard)
Date: Thu, 21 Sep 2023 09:59:54 +0100
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: 
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
 
 <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>
 
 <9ba74ce3-2c21-4682-ba11-fb2491b76bfb@oracle.com>
 
 
Message-ID: 

My only concern might be the fact the MANIFEST would say "Created by:
jdk-N-1", which is still accurate according to the spec:
  "Created-By: Defines the version and the vendor of the java
implementation on top of which this manifest file is generated. This
attribute is generated by the jar tool."
However, people would probably jump to the conclusion that the classes
there in are jdk-N-1 compiled, when they are actually compiled by jdk-N....
Thoughts?

On Wed, Sep 20, 2023 at 10:50?PM  wrote:

> Hello Andrew,
>
> The bootcycle-images target is AFAIK just a test. It's certainly not meant
> to be the authoritative way of building the JDK. Using JDK N-1 as bootjdk
> is the official way of producing a JDK of version JDK N. For convenience,
> and because it should work, we also allow JDK N. Vendors should definitely
> not be encouraged to use bootcycle builds to produce their JDK binaries.
>
> Switching the compiler to interim would help with the reproducibility
> issue. I would support that change. I don't think we can reasonably do
> something about the jar tool.
>
> /Erik
> On 9/20/23 08:12, Andrew Leonard wrote:
>
> Hi Magnus,
>
> So yes, jrt-fs.jar can be different between a normal build and a bootcycle
> build, which is where I sort of came in here... For example, building say
> jdk-21 using a jdk-20 bootjdk, you will find that there is an extra inner
> class in the standard build of jrt-fs.jar, due to the fact that the jdk-21
> compiler optimized the inner class generation for enum's somewhere, such
> that jdk/internal/jrtfs/JrtFileAttributeView$1.class only exists in a
> jdk-20 compiled jrt-fs.jar!
>
> I did experiment, and you can simply switch jrt-fs.jar to be
> COMPILER="interim", however when it comes to the jar's construction via
> "jar", it obviously uses the bootjdk "jar" command since the
> "interim-compiler" is just a compiler....
>
> In summary, I suspect this is just eluding to what the real purpose of
> "bootcycle-images" is, which I think is essentially a "test", and I suspect
> most vendors will either just do a standard "product-images" build, or
> perform their own bootcycle by doing two builds...
>
> Cheers
> Andrew
>
>
>
> On Wed, Sep 20, 2023 at 2:44?PM Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
>
>> On 2023-09-20 09:38, Andrew Leonard wrote:
>>
>> Thanks Alan,
>>
>> So different gcc, glibc, Xcode,.. agree, they need to be the same for
>> identical bits.
>> However, at the moment using the same toolchains, if you do a standard
>> product build,
>> and then a bootcycle build, of the same source, jrt-fs.jar will differ.
>> I'll do some investigation of the make files to see if a "Build JDK"
>> rebuild of jrt-fs.jar is
>> feasible.
>>
>> I would not in general assume that a normal build and a bootcycle build
>> produce identical results. A bootcycle build will build the product using a
>> newer version of the JDK (viz. the one you just build from the sources),
>> and as such, changes to javac can result in different class file outputs,
>> etc. That being said, for large time periods of the JDK source code, a
>> normal build and a bootcycle build can certainly result in the same output,
>> since no changes have been made in the product that affects how .class
>> files are generated. But that is not guaranteed, nor is a difference
>> between normal and bootcycle build a sign of trouble or a defect.
>>
>> If jrt-fs.jar is consistently different between a bootcycle build and a
>> normal build, that sounds a bit odd, though. Especially since it should be
>> built with `--release 8` (or something like that) to ensure it is usable on
>> older Java; and that output ought not to really change as the JDK develops.
>>
>> (Also, questions about the build process is preferably handled on the
>> build-dev list)
>>
>> /Magnus
>>
>>
>>
>> Cheers
>> Andrew
>>
>>
>> On Tue, Sep 19, 2023 at 5:42?PM Alan Bateman 
>> wrote:
>>
>>> On 18/09/2023 14:51, Andrew Leonard wrote:
>>> > Thanks for the clarification Alan.
>>> >
>>> > To ensure the reproducibility of the whole JDK image regardless of the
>>> > specific bootjdk used, would it make sense once the "Build JDK" has
>>> > been built, we re-build jrt-fs.jar again using the "Build JDK" ? Thus
>>> > jrt-fs.jar will be consistent with the rest of the image in terms of
>>> > what it is compiled with.
>>> >
>>>
>>> The boot JDK will be JDK N-1, or the newly built JDK in the case of boot
>>> cycle builds. It seems a bit of a stretch to have builds using different
>>> tool chains to produce identical bits but maybe you mean something else.
>>>
>>> In any case, for jrt-fs.jar the important thing is that they are
>>> compiled to --release 8 (that might rev at some points) so that
>>> IDEs/tools can open a target run-time image as a file system and access
>>> the classes/resources.
>>>
>>> -Alan.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ihse at openjdk.org  Thu Sep 21 09:35:01 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Sep 2023 09:35:01 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 17:19:42 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:
> 
>   change variable names of indexPivot* to pivotIndex*

make/modules/java.base/Lib.gmk line 240:

> 238: 
> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
> 240:   ifeq ($(TOOLCHAIN_TYPE), gcc)

This requirement can be folded into the "and" sequence in the `ifeq` statement above. There is nothing that really merits it to be specified separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1332770004

From liach at openjdk.org  Thu Sep 21 09:35:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 09:35: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

@asotona Since this is your area, can you take a look?
@cl4es Can you review this as well since you are more professional in string optimizations, and can you see if you have similar performance improvements?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15837#issuecomment-1729209220

From redestad at openjdk.org  Thu Sep 21 09:41:33 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 21 Sep 2023 09:41:33 GMT
Subject: Integrated: 8316582: Minor startup regression in 22-b15 due
 JDK-8310929
Message-ID: 

This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`. 

This use is the cause of a small (~1.5ms) startup regression in 22-b15. While a manageable startup regression in and of itself, the use of `VarHandles` in core utility classes brings an increased risk of bootstrap circularity issues, for example disqualifying the use of things like `Integers.toString` in some places.

Reverting this partially rolls back the performance improvement gained by JDK-8310929. It seems reasonable that the compiler can be enhanced to gain that loss back.

-------------

Commit messages:
 - Minor startup regression in 22-b15 due JDK-8310929

Changes: https://git.openjdk.org/jdk/pull/15836/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15836&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316582
  Stats: 31 lines in 2 files changed: 9 ins; 4 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/15836.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15836/head:pull/15836

PR: https://git.openjdk.org/jdk/pull/15836

From liach at openjdk.org  Thu Sep 21 09:41:34 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 09:41:34 GMT
Subject: Integrated: 8316582: Minor startup regression in 22-b15 due
 JDK-8310929
In-Reply-To: 
References: 
Message-ID: <9Sqj8HCE6B5HaV0Mmq_H8qqnuwYGVi1wgjbMgii3F-o=.906fba08-26e1-4a49-83fc-91ed23faf693@github.com>

On Wed, 20 Sep 2023 09:12:48 GMT, Claes Redestad  wrote:

> This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`. 
> 
> This use is the cause of a small (~1.5ms) startup regression in 22-b15. While a manageable startup regression in and of itself, the use of `VarHandles` in core utility classes brings an increased risk of bootstrap circularity issues, for example disqualifying the use of things like `Integers.toString` in some places.
> 
> Reverting this partially rolls back the performance improvement gained by JDK-8310929. It seems reasonable that the compiler can be enhanced to gain that loss back.

Looks good. I also wonder if storing digit pairs in platform endianness is better; currently only Unsafe support writing multibytes with platform endianness.

Can #14636 be a solution to avoid early VH initialization?

Also curious how you created such a "Base vs Test" metrics table, could you teach me how?

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/15836#pullrequestreview-1635269985
PR Comment: https://git.openjdk.org/jdk/pull/15836#issuecomment-1727322352

From rriggs at openjdk.org  Thu Sep 21 09:41:34 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Sep 2023 09:41:34 GMT
Subject: Integrated: 8316582: Minor startup regression in 22-b15 due
 JDK-8310929
In-Reply-To: 
References: 
Message-ID: <9BsRRiw2CuvTfpYWtlGFaajjBWL8tBGEmq7WaZtfC1A=.b0248468-1ffa-4443-a36a-5e5a0c1efa65@github.com>

On Wed, 20 Sep 2023 09:12:48 GMT, Claes Redestad  wrote:

> This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`. 
> 
> This use is the cause of a small (~1.5ms) startup regression in 22-b15. While a manageable startup regression in and of itself, the use of `VarHandles` in core utility classes brings an increased risk of bootstrap circularity issues, for example disqualifying the use of things like `Integers.toString` in some places.
> 
> Reverting this partially rolls back the performance improvement gained by JDK-8310929. It seems reasonable that the compiler can be enhanced to gain that loss back.

Thanks for tracking down the regression.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15836#pullrequestreview-1636230022

From redestad at openjdk.org  Thu Sep 21 09:41:35 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 21 Sep 2023 09:41:35 GMT
Subject: Integrated: 8316582: Minor startup regression in 22-b15 due
 JDK-8310929
In-Reply-To: 
References: 
Message-ID: <8jLkJjHqhW2AmRbdaSKY-sb9WvM9RyOy8pxCPOJ_CZc=.3856a82e-93fd-446e-8e52-517d6bb2897a@github.com>

On Wed, 20 Sep 2023 09:12:48 GMT, Claes Redestad  wrote:

> This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`. 
> 
> This use is the cause of a small (~1.5ms) startup regression in 22-b15. While a manageable startup regression in and of itself, the use of `VarHandles` in core utility classes brings an increased risk of bootstrap circularity issues, for example disqualifying the use of things like `Integers.toString` in some places.
> 
> Reverting this partially rolls back the performance improvement gained by JDK-8310929. It seems reasonable that the compiler can be enhanced to gain that loss back.

This PR vs a 22-b15 baseline:

Name                   Cnt  Base   Error   Test   Error  Unit   Diff%
Integers.toStringBig    15 5,318 ? 0,043  6,628 ? 0,127 us/op  -24,6% (p = 0,000*)
Integers.toStringSmall  15 3,202 ? 0,018  3,562 ? 0,027 us/op  -11,2% (p = 0,000*)
Integers.toStringTiny   15 2,286 ? 0,017  2,352 ? 0,024 us/op   -2,9% (p = 0,000*)
  * = significant


This PR vs a 22-b14 baseline:

Name                   Cnt   Base   Error   Test   Error  Unit   Diff%
Integers.toStringBig    15 12,313 ? 0,143  6,628 ? 0,127 us/op   46,2% (p = 0,000*)
Integers.toStringSmall  15  4,816 ? 0,074  3,562 ? 0,027 us/op   26,0% (p = 0,000*)
Integers.toStringTiny   15  2,611 ? 0,022  2,352 ? 0,024 us/op    9,9% (p = 0,000*)
  * = significant


There's still a substantial win compared to 22-b14, stemming from the use of a packed lookup table rather than two disjoint tables for tens and single digit numbers.

Startup numbers improve with the above patch to levels on par with 22-b14:

Name                Cnt          Base         Error           Test         Error         Unit   Diff%
Perfstartup-Noop-G1  20        30,000 ?       0,000         28,500 ?       3,181        ms/op    5,0% (p = 0,083 )
  :.cycles           20  88166516,750 ? 2119868,114   84226439,550 ? 1792195,203       cycles   -4,5% (p = 0,000*)
  :.instructions     20 204321816,400 ?  248867,819  195313416,200 ?  196361,902 instructions   -4,4% (p = 0,000*)
  :.taskclock        20        12,000 ?       4,543         10,000 ?       0,000           ms  -16,7% (p = 0,104 )
  * = significant

(This is simply a Noop/Hello World program in a loop, with stats collected by `/usr/bin/time -l`, run on a MacBook M1)

FWIW when initializing `DIGITS` directly (`DIGITS = new byte[] { ...`)  the `DecimalDigits` class is 2610 bytes, with the for loop in a `static` block it drops down to 2112 bytes. Array constants like this generate sad and bloated bytecode:

         0: bipush        100
         2: newarray       short
         4: dup
         5: iconst_0
         6: sipush        12336
         9: sastore
         ...
        40: dup
        41: bipush        6
        43: sipush        13872
        46: sastore
        ...
       691: dup
       692: bipush        99
       694: sipush        14649
       697: sastore
       698: putstatic     #13                 // Field DIGITS:[S

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15836#issuecomment-1727317896
PR Comment: https://git.openjdk.org/jdk/pull/15836#issuecomment-1727402036
PR Comment: https://git.openjdk.org/jdk/pull/15836#issuecomment-1727935701

From redestad at openjdk.org  Thu Sep 21 09:41:37 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 21 Sep 2023 09:41:37 GMT
Subject: Integrated: 8316582: Minor startup regression in 22-b15 due
 JDK-8310929
In-Reply-To: <9Sqj8HCE6B5HaV0Mmq_H8qqnuwYGVi1wgjbMgii3F-o=.906fba08-26e1-4a49-83fc-91ed23faf693@github.com>
References: 
 <9Sqj8HCE6B5HaV0Mmq_H8qqnuwYGVi1wgjbMgii3F-o=.906fba08-26e1-4a49-83fc-91ed23faf693@github.com>
Message-ID: <-lja518675G-c0xTfgMIAYptwcRjq5OWyOdnIbhfDwY=.70d83b37-6579-4551-849e-37d2d0d142bf@github.com>

On Wed, 20 Sep 2023 09:21:00 GMT, Chen Liang  wrote:

> Can #14636 be a solution to avoid early VH initialization?

I think #14636 would more or less solve the startup regression, yes, but the jury is out on whether we want to accept that. There's value in taking steps to make `VH` indistinguishable from `Unsafe` w.r.t. start-up and other performance characteristics. The issue with using `ByteArray*` in `Integer/StringLatin1` is also more one of bootstrap dependencies. 

We also really need to analyze why the JIT doesn't generate as good code for pair-wise `byte[]` stores as for `ByteArray.setShort` and then try to fix this in the JIT. This would be much preferable to having to pull out a power tool like `ByteArrayLittleEndian` for something so trivial. It might be a good exercise for anyone who want to dive into JITs to get these to perform equally. 

> Also curious how you created such a "Base vs Test" metrics table, could you teach me how?

It's a tool I've written that parses JMH json output and allows comparisons. It's currently part of a larger benchmark running toolkit that we probably can't open source, but I could probably extract the simple parser + printer and put it under the OpenJDK somewhere if there's interest.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15836#issuecomment-1727356469

From redestad at openjdk.org  Thu Sep 21 09:41:38 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 21 Sep 2023 09:41:38 GMT
Subject: Integrated: 8316582: Minor startup regression in 22-b15 due
 JDK-8310929
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 09:12:48 GMT, Claes Redestad  wrote:

> This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`. 
> 
> This use is the cause of a small (~1.5ms) startup regression in 22-b15. While a manageable startup regression in and of itself, the use of `VarHandles` in core utility classes brings an increased risk of bootstrap circularity issues, for example disqualifying the use of things like `Integers.toString` in some places.
> 
> Reverting this partially rolls back the performance improvement gained by JDK-8310929. It seems reasonable that the compiler can be enhanced to gain that loss back.

This pull request has now been integrated.

Changeset: 913e43fe
Author:    Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/913e43fea995b746fb9e1b25587d254396c7c3c9
Stats:     31 lines in 2 files changed: 9 ins; 4 del; 18 mod

8316582: Minor startup regression in 22-b15 due JDK-8310929

Reviewed-by: liach, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/15836

From magnus.ihse.bursie at oracle.com  Thu Sep 21 09:48:51 2023
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 21 Sep 2023 11:48:51 +0200
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: 
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
 
 <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>
 
 <9ba74ce3-2c21-4682-ba11-fb2491b76bfb@oracle.com>
 
 
 
Message-ID: 

On 2023-09-21 10:59, Andrew Leonard wrote:

> My only concern might be the fact the MANIFEST would say "Created by: 
> jdk-N-1", which is still accurate according to the spec:
> ? "Created-By: Defines the version and the vendor of the java 
> implementation on top of which this manifest file is generated. This 
> attribute is generated by the jar tool."
> However, people would probably jump to the conclusion that the classes 
> there in are jdk-N-1 compiled, when they are actually compiled by 
> jdk-N....
> Thoughts?

If the definition of the `Created by` field says it is set by the jar 
tool that generated the jar file, then this is as it should be, and we 
should not try to change it.

It is not in our powers to stop people from jumping to (incorrect) 
conclusions, based on their misunderstanding of the specifications (even 
though I often wished that it were...).

/Magnus



>
> On Wed, Sep 20, 2023 at 10:50?PM  wrote:
>
>     Hello Andrew,
>
>     The bootcycle-images target is AFAIK just a test. It's certainly
>     not meant to be the authoritative way of building the JDK. Using
>     JDK N-1 as bootjdk is the official way of producing a JDK of
>     version JDK N. For convenience, and because it should work, we
>     also allow JDK N. Vendors should definitely not be encouraged to
>     use bootcycle builds to produce their JDK binaries.
>
>     Switching the compiler to interim would help with the
>     reproducibility issue. I would support that change. I don't think
>     we can reasonably do something about the jar tool.
>
>     /Erik
>
>     On 9/20/23 08:12, Andrew Leonard wrote:
>>     Hi Magnus,
>>
>>     So yes, jrt-fs.jar can be different between a normal build and a
>>     bootcycle build, which is where I sort of came in here... For
>>     example, building say jdk-21 using a jdk-20 bootjdk, you will
>>     find that there is an extra inner class in the standard build of
>>     jrt-fs.jar, due to the fact that the jdk-21 compiler optimized
>>     the inner class generation for enum's somewhere, such that
>>     jdk/internal/jrtfs/JrtFileAttributeView$1.class only exists in a
>>     jdk-20 compiled jrt-fs.jar!
>>
>>     I did experiment, and you can simply switch jrt-fs.jar to be
>>     COMPILER="interim", however when it comes to the jar's
>>     construction via "jar", it obviously uses the bootjdk "jar"
>>     command since the "interim-compiler" is just a compiler....
>>
>>     In summary, I suspect this is just eluding to what the real
>>     purpose of "bootcycle-images" is, which I think is essentially a
>>     "test", and I suspect most vendors will either just do a standard
>>     "product-images" build, or perform their own bootcycle by doing
>>     two builds...
>>
>>     Cheers
>>     Andrew
>>
>>
>>
>>     On Wed, Sep 20, 2023 at 2:44?PM Magnus Ihse Bursie
>>      wrote:
>>
>>         On 2023-09-20 09:38, Andrew Leonard wrote:
>>
>>>         Thanks Alan,
>>>
>>>         So different gcc, glibc, Xcode,.. agree, they need to be the
>>>         same for identical bits.
>>>         However, at the moment using the same toolchains, if you do
>>>         a standard product build,
>>>         and then a bootcycle build, of the same source, jrt-fs.jar
>>>         will differ.
>>>         I'll do some investigation of the make files to see if a
>>>         "Build JDK" rebuild of jrt-fs.jar is
>>>         feasible.
>>
>>         I would not in general assume that a normal build and a
>>         bootcycle build produce identical results. A bootcycle build
>>         will build the product using a newer version of the JDK (viz.
>>         the one you just build from the sources), and as such,
>>         changes to javac can result in different class file outputs,
>>         etc. That being said, for large time periods of the JDK
>>         source code, a normal build and a bootcycle build can
>>         certainly result in the same output, since no changes have
>>         been made in the product that affects how .class files are
>>         generated. But that is not guaranteed, nor is a difference
>>         between normal and bootcycle build a sign of trouble or a defect.
>>
>>         If jrt-fs.jar is consistently different between a bootcycle
>>         build and a normal build, that sounds a bit odd, though.
>>         Especially since it should be built with `--release 8` (or
>>         something like that) to ensure it is usable on older Java;
>>         and that output ought not to really change as the JDK develops.
>>
>>         (Also, questions about the build process is preferably
>>         handled on the build-dev list)
>>
>>         /Magnus
>>
>>
>>>
>>>         Cheers
>>>         Andrew
>>>
>>>
>>>         On Tue, Sep 19, 2023 at 5:42?PM Alan Bateman
>>>          wrote:
>>>
>>>             On 18/09/2023 14:51, Andrew Leonard wrote:
>>>             > Thanks for the clarification Alan.
>>>             >
>>>             > To ensure the reproducibility of the whole JDK image
>>>             regardless of the
>>>             > specific bootjdk used, would it make sense once the
>>>             "Build JDK" has
>>>             > been built, we re-build jrt-fs.jar again using the
>>>             "Build JDK" ? Thus
>>>             > jrt-fs.jar will be consistent with the rest of the
>>>             image in terms of
>>>             > what it is compiled with.
>>>             >
>>>
>>>             The boot JDK will be JDK N-1, or the newly built JDK in
>>>             the case of boot
>>>             cycle builds. It seems a bit of a stretch to have builds
>>>             using different
>>>             tool chains to produce identical bits but maybe you mean
>>>             something else.
>>>
>>>             In any case, for jrt-fs.jar the important thing is that
>>>             they are
>>>             compiled to --release 8 (that might rev at some points)
>>>             so that
>>>             IDEs/tools can open a target run-time image as a file
>>>             system and access
>>>             the classes/resources.
>>>
>>>             -Alan.
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From asotona at openjdk.org  Thu Sep 21 11:48:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Sep 2023 11:48:45 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

I would integrate conversions that are ready, otherwise the work spend to fix and reflect changes would double in the preview branch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1729406198

From jvernee at openjdk.org  Thu Sep 21 12:21:45 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 21 Sep 2023 12:21:45 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 21 Sep 2023 06:08:27 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
>> 
>> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
>> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
>> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
>> 
>> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
>> No new tests. Existing tier1-2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline variable declaration

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15789#pullrequestreview-1637680396

From redestad at openjdk.org  Thu Sep 21 12:21:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 21 Sep 2023 12:21:46 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

I can verify the improvement locally in your added micro:

Name                            Cnt         Base    Error          Test    Error   Unit   Diff%
ReadMetadata.jdkReadMemberNames   4      108.234 ?  1.089       114.953 ?  0.709  ops/s    6.2% (p = 0.000*)

I don't have domain expertise w.r.t the classfile API to value how much this will benefit typical use-cases, but it seem like a straightforward enough improvement to me. (At least the `vectorizedHashCode` has the nice property that it's always faster than a naive `31 * hash + v` loop, even when inputs are too small to actually benefit from SIMD instructions).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15837#issuecomment-1729454730

From djelinski at openjdk.org  Thu Sep 21 12:42:53 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 21 Sep 2023 12:42:53 GMT
Subject: RFR: 8316421: libjava should load shell32.dll eagerly [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 21 Sep 2023 06:08:27 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
>> 
>> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
>> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
>> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
>> 
>> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
>> No new tests. Existing tier1-2 tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline variable declaration

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15789#issuecomment-1729482917

From djelinski at openjdk.org  Thu Sep 21 12:42:54 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 21 Sep 2023 12:42:54 GMT
Subject: Integrated: 8316421: libjava should load shell32.dll eagerly
In-Reply-To: 
References: 
Message-ID: <3yR_ExCKUFKakh0rjqFJ8lOguplrZJTcG4kIDjRblW8=.d5154548-26a1-4403-917b-6ad5084b878a@github.com>

On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeli?ski  wrote:

> Please review this patch that makes java.dll load shell32.dll earlier. Delay-loading requires some additional code (delayimp.lib), and offers no benefits since we always load shell32 during JVM startup.
> 
> Other than removing the delayload clause, the patch also cleans up the `getHomeFromShell32` method:
> - the WinXP code path is removed. The documentation states that [the older function just calls the new one with translated parameters](https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha).
> - `CoTaskMemFree` is now called if `SHGetKnownFolderPath` fails. This is suggested by the documentation, but probably never needed in practice.
> 
> This change shouldn't have any observable effect on behavior on any of the supported operating systems. It reduced the size of java.dll by 2KB on my machine.
> No new tests. Existing tier1-2 tests continue to pass.

This pull request has now been integrated.

Changeset: 8cbe42b9
Author:    Daniel Jeli?ski 
URL:       https://git.openjdk.org/jdk/commit/8cbe42b94aaf2ff090ae8399da0418e9e2fc3873
Stats:     37 lines in 2 files changed: 0 ins; 31 del; 6 mod

8316421: libjava should load shell32.dll eagerly

Reviewed-by: erikj, jwaters, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/15789

From rgiulietti at openjdk.org  Thu Sep 21 13:01:10 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 21 Sep 2023 13:01:10 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float)
Message-ID: 

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.

-------------

Commit messages:
 - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float)

Changes: https://git.openjdk.org/jdk/pull/15861/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15861&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316662
  Stats: 388 lines in 3 files changed: 161 ins; 108 del; 119 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  Thu Sep 21 13:03:51 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Thu, 21 Sep 2023 13:03:51 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float)
In-Reply-To: 
References: 
Message-ID: 

On Thu, 21 Sep 2023 12:51:56 GMT, Raffaello Giulietti  wrote:

> 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.

I bet that `decNumberOfTrailingZeros` call will increase serialization time for values with short mantissa (like 1.23e-4) due to a dozen of dependent multiplication operations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15861#issuecomment-1729520371

From rgiulietti at openjdk.org  Thu Sep 21 13:09:40 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 21 Sep 2023 13:09:40 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float)
In-Reply-To: 
References: 
Message-ID: 

On Thu, 21 Sep 2023 12:51:56 GMT, Raffaello Giulietti  wrote:

> 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.

On my platform, conversions are never slower and are faster on short significands.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15861#issuecomment-1729530394

From anleonar at redhat.com  Thu Sep 21 13:14:42 2023
From: anleonar at redhat.com (Andrew Leonard)
Date: Thu, 21 Sep 2023 14:14:42 +0100
Subject: Should we build jrt-fs.jar again with the "Build JDK" ?
In-Reply-To: 
References: 
 <2df96a7f-00c9-372f-517f-0efdee954ed9@oracle.com>
 
 <63b9ebb0-d9f6-6813-fc5e-beb9bf944b33@oracle.com>
 
 <9ba74ce3-2c21-4682-ba11-fb2491b76bfb@oracle.com>
 
 
 
 
Message-ID: 

Thanks Magnus, yeah it is still doing as it says on the "tin", so I think
i'm just being paranoid! I'll put a PR together for review, cheers

On Thu, Sep 21, 2023 at 10:49?AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2023-09-21 10:59, Andrew Leonard wrote:
>
> My only concern might be the fact the MANIFEST would say "Created by:
> jdk-N-1", which is still accurate according to the spec:
>   "Created-By: Defines the version and the vendor of the java
> implementation on top of which this manifest file is generated. This
> attribute is generated by the jar tool."
> However, people would probably jump to the conclusion that the classes
> there in are jdk-N-1 compiled, when they are actually compiled by jdk-N....
> Thoughts?
>
> If the definition of the `Created by` field says it is set by the jar tool
> that generated the jar file, then this is as it should be, and we should
> not try to change it.
>
> It is not in our powers to stop people from jumping to (incorrect)
> conclusions, based on their misunderstanding of the specifications (even
> though I often wished that it were...).
>
> /Magnus
>
>
>
>
> On Wed, Sep 20, 2023 at 10:50?PM  wrote:
>
>> Hello Andrew,
>>
>> The bootcycle-images target is AFAIK just a test. It's certainly not
>> meant to be the authoritative way of building the JDK. Using JDK N-1 as
>> bootjdk is the official way of producing a JDK of version JDK N. For
>> convenience, and because it should work, we also allow JDK N. Vendors
>> should definitely not be encouraged to use bootcycle builds to produce
>> their JDK binaries.
>>
>> Switching the compiler to interim would help with the reproducibility
>> issue. I would support that change. I don't think we can reasonably do
>> something about the jar tool.
>>
>> /Erik
>> On 9/20/23 08:12, Andrew Leonard wrote:
>>
>> Hi Magnus,
>>
>> So yes, jrt-fs.jar can be different between a normal build and a
>> bootcycle build, which is where I sort of came in here... For example,
>> building say jdk-21 using a jdk-20 bootjdk, you will find that there is an
>> extra inner class in the standard build of jrt-fs.jar, due to the fact that
>> the jdk-21 compiler optimized the inner class generation for enum's
>> somewhere, such that jdk/internal/jrtfs/JrtFileAttributeView$1.class only
>> exists in a jdk-20 compiled jrt-fs.jar!
>>
>> I did experiment, and you can simply switch jrt-fs.jar to be
>> COMPILER="interim", however when it comes to the jar's construction via
>> "jar", it obviously uses the bootjdk "jar" command since the
>> "interim-compiler" is just a compiler....
>>
>> In summary, I suspect this is just eluding to what the real purpose of
>> "bootcycle-images" is, which I think is essentially a "test", and I suspect
>> most vendors will either just do a standard "product-images" build, or
>> perform their own bootcycle by doing two builds...
>>
>> Cheers
>> Andrew
>>
>>
>>
>> On Wed, Sep 20, 2023 at 2:44?PM Magnus Ihse Bursie <
>> magnus.ihse.bursie at oracle.com> wrote:
>>
>>> On 2023-09-20 09:38, Andrew Leonard wrote:
>>>
>>> Thanks Alan,
>>>
>>> So different gcc, glibc, Xcode,.. agree, they need to be the same for
>>> identical bits.
>>> However, at the moment using the same toolchains, if you do a standard
>>> product build,
>>> and then a bootcycle build, of the same source, jrt-fs.jar will differ.
>>> I'll do some investigation of the make files to see if a "Build JDK"
>>> rebuild of jrt-fs.jar is
>>> feasible.
>>>
>>> I would not in general assume that a normal build and a bootcycle build
>>> produce identical results. A bootcycle build will build the product using a
>>> newer version of the JDK (viz. the one you just build from the sources),
>>> and as such, changes to javac can result in different class file outputs,
>>> etc. That being said, for large time periods of the JDK source code, a
>>> normal build and a bootcycle build can certainly result in the same output,
>>> since no changes have been made in the product that affects how .class
>>> files are generated. But that is not guaranteed, nor is a difference
>>> between normal and bootcycle build a sign of trouble or a defect.
>>>
>>> If jrt-fs.jar is consistently different between a bootcycle build and a
>>> normal build, that sounds a bit odd, though. Especially since it should be
>>> built with `--release 8` (or something like that) to ensure it is usable on
>>> older Java; and that output ought not to really change as the JDK develops.
>>>
>>> (Also, questions about the build process is preferably handled on the
>>> build-dev list)
>>>
>>> /Magnus
>>>
>>>
>>>
>>> Cheers
>>> Andrew
>>>
>>>
>>> On Tue, Sep 19, 2023 at 5:42?PM Alan Bateman 
>>> wrote:
>>>
>>>> On 18/09/2023 14:51, Andrew Leonard wrote:
>>>> > Thanks for the clarification Alan.
>>>> >
>>>> > To ensure the reproducibility of the whole JDK image regardless of
>>>> the
>>>> > specific bootjdk used, would it make sense once the "Build JDK" has
>>>> > been built, we re-build jrt-fs.jar again using the "Build JDK" ? Thus
>>>> > jrt-fs.jar will be consistent with the rest of the image in terms of
>>>> > what it is compiled with.
>>>> >
>>>>
>>>> The boot JDK will be JDK N-1, or the newly built JDK in the case of
>>>> boot
>>>> cycle builds. It seems a bit of a stretch to have builds using
>>>> different
>>>> tool chains to produce identical bits but maybe you mean something else.
>>>>
>>>> In any case, for jrt-fs.jar the important thing is that they are
>>>> compiled to --release 8 (that might rev at some points) so that
>>>> IDEs/tools can open a target run-time image as a file system and access
>>>> the classes/resources.
>>>>
>>>> -Alan.
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From asotona at openjdk.org  Thu Sep 21 13:46:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Sep 2023 13:46:41 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

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 236:

> 234:         private void inflate() {
> 235:             int singleBytes = JLA.countPositives(rawBytes, offset, rawLen);
> 236:             int hash = ArraysSupport.vectorizedHashCode(rawBytes, offset, singleBytes, 0, ArraysSupport.T_BOOLEAN);

We should keep in mind that this code is on lambdas bootstrap critical path.
Any foreign code may involve lambdas or method references and cause dead end in lambdas initialization after JDK-8294960.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15837#discussion_r1333082244

From jvernee at openjdk.org  Thu Sep 21 13:53:44 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 21 Sep 2023 13:53:44 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 21 Sep 2023 08:50:00 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:
> 
>   byte array var handles can share a common base class

The X-VarHandleSegmentView.java.template and VarHandleSegmentViewBase.java files have diverged in the panama-foreign repo. Please break out the changes to those files and submit them to the panama-foreign repo instead. This will avoid having to resolve merge conflicts in the changed code.

Alternatively, you could make a PR for those changes in this repo that is dependent on the [JEP patch for 22](https://github.com/openjdk/jdk/pull/15103), which also contain the changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15854#issuecomment-1729628087

From liach at openjdk.org  Thu Sep 21 13:57:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 13:57:45 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 13:43:30 GMT, Adam Sotona  wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix logical bug with char array filling
>
> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 236:
> 
>> 234:         private void inflate() {
>> 235:             int singleBytes = JLA.countPositives(rawBytes, offset, rawLen);
>> 236:             int hash = ArraysSupport.vectorizedHashCode(rawBytes, offset, singleBytes, 0, ArraysSupport.T_BOOLEAN);
> 
> We should keep in mind that this code is on lambdas bootstrap critical path.
> Any foreign code may involve lambdas or method references and cause dead end in lambdas initialization after JDK-8294960.

This is safe: these two functions are already used in String itself (see StringLatin1) which is definitely loaded and initialized before Classfile API and its implementations are.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15837#discussion_r1333101060

From duke at openjdk.org  Thu Sep 21 14:58:46 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 21 Sep 2023 14:58:46 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v4]
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 four 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
 - use ByteArrayLittleEndian in ZipUtils

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14632/files
  - new: https://git.openjdk.org/jdk/pull/14632/files/c14b9620..49520bbf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=02-03

  Stats: 259502 lines in 5448 files changed: 106976 ins; 98816 del; 53710 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  Thu Sep 21 15:00:44 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 21 Sep 2023 15:00:44 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v11]
In-Reply-To: 
References: 
Message-ID: <1kuYfDrWhOiWmrvJwLPJ_QdF5QRrCh40PNeiuAZPfEI=.3fa3e530-b2b1-4aa2-aa9a-2ccb7c9c7411@github.com>

> `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.

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 16 additional commits since the last revision:

 - Merge branch 'openjdk:master' into unsafe
 - Merge branch 'openjdk:master' into unsafe
 - add 8310843 to @bug
 - Merge branch 'openjdk:master' into unsafe
 - Merge branch 'openjdk:master' into unsafe
 - delete incorrect comments
 - delete extraneous whitespace
 - add javadoc
 - delete extraneous whitespace
 - fix test
 - ... and 6 more: https://git.openjdk.org/jdk/compare/d1e02f97...6560d358

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/cb56e736..6560d358

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=09-10

  Stats: 188052 lines in 4685 files changed: 89964 ins; 47362 del; 50726 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From bpb at openjdk.org  Thu Sep 21 15:35:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Sep 2023 15:35:16 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v9]
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: 

> Add a `finally` block to delete the created files.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8315960: Use assertEquals

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15757/files
  - new: https://git.openjdk.org/jdk/pull/15757/files/b3ac8c7b..cc4a3369

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15757&range=07-08

  Stats: 9 lines in 1 file changed: 1 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15757/head:pull/15757

PR: https://git.openjdk.org/jdk/pull/15757

From bpb at openjdk.org  Thu Sep 21 15:35:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Sep 2023 15:35:16 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v8]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
 
Message-ID: 

On Thu, 21 Sep 2023 05:26:38 GMT, Daniel Jeli?ski  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8315960: Address additional reviewer comments
>
> test/jdk/java/io/File/TempDirDoesNotExist.java line 142:
> 
>> 140:         OutputAnalyzer originalOutput = ProcessTools.executeTestJvm(options);
>> 141:         List list = originalOutput.asLines().stream().filter(line
>> 142:                 -> line.equalsIgnoreCase(WARNING)).toList();
> 
> You could use `count` instead of `toList`; the actual list is never used in this test

Fixed in cc4a3369871d8ad66162133e51bf625dfcf9b62c.

> test/jdk/java/io/File/TempDirDoesNotExist.java line 143:
> 
>> 141:         List list = originalOutput.asLines().stream().filter(line
>> 142:                 -> line.equalsIgnoreCase(WARNING)).toList();
>> 143:         if (list.size() != 1)
> 
> Use assertEquals

Fixed in cc4a3369871d8ad66162133e51bf625dfcf9b62c.

> test/jdk/java/io/File/TempDirDoesNotExist.java line 148:
> 
>> 146:                                        originalOutput.asLines().toString());
>> 147:         int exitValue = originalOutput.getExitValue();
>> 148:         if (exitValue != 0)
> 
> Use assertEquals

Fixed in cc4a3369871d8ad66162133e51bf625dfcf9b62c.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1333256900
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1333256321
PR Review Comment: https://git.openjdk.org/jdk/pull/15757#discussion_r1333256536

From lancea at openjdk.org  Thu Sep 21 15:53:40 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 21 Sep 2023 15:53:40 GMT
Subject: RFR: 8316383: NullPointerException in AbstractSAXParser after
 JDK-8306632
In-Reply-To: 
References: 
Message-ID: 

On Tue, 19 Sep 2023 21:10:41 GMT, Joe Wang  wrote:

> Fix a NPE. The DTD patch (JDK-8306632) moved initialization to factories, for example, for SAXParser, the SecurityManagers are created in the SAXParserFactory impl and passed on to instances of SAXParsers. The (deprecated) XMLReaderFactory however, instantiates SAXParsers directly, thus without initializing the SecurityManagers. This patch checks the condition and creates them if they have not already been constructed.
> 
> Test: XML tests passed.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15828#pullrequestreview-1638204539

From djelinski at openjdk.org  Thu Sep 21 16:32:43 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 21 Sep 2023 16:32:43 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v9]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
Message-ID: 

On Thu, 21 Sep 2023 15:35:16 GMT, Brian Burkhalter  wrote:

>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315960: Use assertEquals

LGTM. Thanks!

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15757#pullrequestreview-1638280276

From bpb at openjdk.org  Thu Sep 21 16:36:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Sep 2023 16:36:46 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v9]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
 
Message-ID: 

On Thu, 21 Sep 2023 16:30:15 GMT, Daniel Jeli?ski  wrote:

> LGTM. Thanks!

Thanks (to everyone) for the constructive comments!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15757#issuecomment-1729921947

From naoto at openjdk.org  Thu Sep 21 16:38:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 21 Sep 2023 16:38:44 GMT
Subject: RFR: 8316383: NullPointerException in AbstractSAXParser after
 JDK-8306632
In-Reply-To: 
References: 
Message-ID: <2kvmu58oym39fDFsPooYJF9V_cn6Mc78sIWDUjpFtoE=.8a185f97-e277-4d25-820c-4c3697de03ea@github.com>

On Tue, 19 Sep 2023 21:10:41 GMT, Joe Wang  wrote:

> Fix a NPE. The DTD patch (JDK-8306632) moved initialization to factories, for example, for SAXParser, the SecurityManagers are created in the SAXParserFactory impl and passed on to instances of SAXParsers. The (deprecated) XMLReaderFactory however, instantiates SAXParsers directly, thus without initializing the SecurityManagers. This patch checks the condition and creates them if they have not already been constructed.
> 
> Test: XML tests passed.

LGTM.

src/java.xml/share/classes/jdk/xml/internal/Utils.java line 42:

> 40:      * and used to print out information related to the configuration of factories
> 41:      * and processors
> 42:     */

Super nit: indentation

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15828#pullrequestreview-1638286810
PR Review Comment: https://git.openjdk.org/jdk/pull/15828#discussion_r1333338758

From pminborg at openjdk.org  Thu Sep 21 16:40:59 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Sep 2023 16:40:59 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v3]
In-Reply-To: 
References: 
Message-ID: <8Y_HVJGTPU6vuu1YlwLrHJvAzNCTekesg6eSmGZu3QI=.5ff02864-ec82-4c2a-a21a-13d987852ff9@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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into 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:
  - all: https://git.openjdk.org/jdk/pull/15614/files
  - new: https://git.openjdk.org/jdk/pull/15614/files/2cb090b6..18cfff84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=01-02

  Stats: 68207 lines in 2244 files changed: 20382 ins; 12922 del; 34903 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 psandoz at openjdk.org  Thu Sep 21 16:48:00 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 21 Sep 2023 16:48:00 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 17:19:42 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:
> 
>   change variable names of indexPivot* to pivotIndex*

test/jdk/java/util/Arrays/Sorting.java line 30:

> 28:  * @build Sorting
> 29:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySort,_arrayPartition, Sorting -shortrun
> 30:  * @run main/othervm -XX:CompileThreshold=1 -XX:-TieredCompilation Sorting -shortrun

It would be useful to target the compilation threshold only for the intrinsic methods, but i suspect that is not possible?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1333351101

From lancea at openjdk.org  Thu Sep 21 17:07:41 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 21 Sep 2023 17:07:41 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v9]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
Message-ID: 

On Thu, 21 Sep 2023 15:35:16 GMT, Brian Burkhalter  wrote:

>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315960: Use assertEquals

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15757#pullrequestreview-1638338199

From psandoz at openjdk.org  Thu Sep 21 17:37:57 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 21 Sep 2023 17:37:57 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 20 Sep 2023 17:19:42 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:
> 
>   change variable names of indexPivot* to pivotIndex*

The Java changes look good to me, it slots in very neatly with the same space/memory characteristics. It's generally pleasing to me to see recent data parallel sorting techniques from academic literature applied in the Java platform.

I wish it were easier to support different OS platforms (e.g., MacOS with x86) but its a compromise on complexity of the sort implementations. 

I wonder if it makes sense to adjust the insertion sort thresholds when the intrinsics are enabled. That could be revisited later.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14227#pullrequestreview-1638385858

From mchung at openjdk.org  Thu Sep 21 18:16:27 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 21 Sep 2023 18:16:27 GMT
Subject: RFR: 8316456: StackWalker may skip Continuation::yield0 frame
 mistakenly
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 21 Sep 2023 05:15:26 GMT, Patricio Chilano Mateo  wrote:

>> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
>> stream is currently at the frame decoded in the last patch and so always
>> advances to the next frame before filling in the new batch of stack frame.
>> However `JVM_MoreStackWalk` may return 0.  The library will set 
>> the continuation to its parent. It then call `JVM_MoreStackWalk` to continue
>> the stack walking but the last decoded frame has already been advanced.
>> The Java frame stream is already at the top frame of the parent continuation. .
>> The current implementation skips "Continuation::yield0" mistakenly.  This
>> only happens with `-XX:+ShowHiddenFrames` or `StackWalker.Option.SHOW_HIDDEN_FRAMES`.
>> 
>> The fix is to pass the number of frames decoded in the last batch to `JVM_MoreStackWalk`
>> so that the VM will determine if the current frame should be skipped or not.
>> 
>> `test/jdk/jdk/internal/vm/Continuation/Scoped.java` test now correctly checks
>> the expected result where "yield0" exists between "enter" and "run" frames.
>
> src/java.base/share/classes/java/lang/StackStreamFactory.java line 443:
> 
>> 441: 
>> 442:             // If the last batch didn't fetch any frames, keep the current batch size.
>> 443:             int lastBatchFrameCount = frameBuffer.numFrames();
> 
> I run some tests to understand the issue and I got the same failure if I now set MIN_BATCH_SIZE to 7. This just forces the same situation where Continuation::enter is the last frame in the buffer, otherwise since the patch also changes the batch sizes we don't fall into that issue anymore. The problem is with this numFrames() method which still returns a number > 0 after the fetch attempt that returns with no frames. Maybe there is a reset missing for origin and fence when fetching the next batch?

Thanks for catching this.   The problem is that `fetchStackFrames(int batchSize)` is supposed to call `setBatch` to set origin and fence for the new batch.  But if no frame is fetched, it skips not calling that.   I have a fix for it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15804#discussion_r1333433443

From mchung at openjdk.org  Thu Sep 21 18:20:36 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 21 Sep 2023 18:20:36 GMT
Subject: RFR: 8316456: StackWalker may skip Continuation::yield0 frame
 mistakenly [v2]
In-Reply-To: 
References: 
Message-ID: 

> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
> stream is currently at the frame decoded in the last patch and so always
> advances to the next frame before filling in the new batch of stack frame.
> However `JVM_MoreStackWalk` may return 0.  The library will set 
> the continuation to its parent. It then call `JVM_MoreStackWalk` to continue
> the stack walking but the last decoded frame has already been advanced.
> The Java frame stream is already at the top frame of the parent continuation. .
> The current implementation skips "Continuation::yield0" mistakenly.  This
> only happens with `-XX:+ShowHiddenFrames` or `StackWalker.Option.SHOW_HIDDEN_FRAMES`.
> 
> The fix is to pass the number of frames decoded in the last batch to `JVM_MoreStackWalk`
> so that the VM will determine if the current frame should be skipped or not.
> 
> `test/jdk/jdk/internal/vm/Continuation/Scoped.java` test now correctly checks
> the expected result where "yield0" exists between "enter" and "run" frames.

Mandy Chung has updated the pull request with a new target base 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' of https://github.com/openjdk/jdk into JDK-8316456
 - call setBatch to update origin and fence for an empty batch
 - 8316456: StackWalker may skip Continuation::yield0 frame mistakenly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15804/files
  - new: https://git.openjdk.org/jdk/pull/15804/files/f3ec0dac..ddaeaf99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15804&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15804&range=00-01

  Stats: 19285 lines in 295 files changed: 11045 ins; 7282 del; 958 mod
  Patch: https://git.openjdk.org/jdk/pull/15804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15804/head:pull/15804

PR: https://git.openjdk.org/jdk/pull/15804

From duke at openjdk.org  Thu Sep 21 18:37:50 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 21 Sep 2023 18:37:50 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 21 Sep 2023 09:32:18 GMT, Magnus Ihse Bursie  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change variable names of indexPivot* to pivotIndex*
>
> make/modules/java.base/Lib.gmk line 240:
> 
>> 238: 
>> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
>> 240:   ifeq ($(TOOLCHAIN_TYPE), gcc)
> 
> This requirement can be folded into the "and" sequence in the `ifeq` statement above. There is nothing that really merits it to be specified separately.

Hello Magnus (@magicus),

As suggested, made the modification to use a single `ifeq` (which works for me on a Linux machine). Could you please confirm if the approach below is correct? 

`ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2)+$(filter $(TOOLCHAIN_TYPE), gcc), true+true+true+gcc)`

Thanks,
Vamsi

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1333450204

From naoto at openjdk.org  Thu Sep 21 18:51:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 21 Sep 2023 18:51:55 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v2]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
 
Message-ID: 

On Thu, 21 Sep 2023 07:17:43 GMT, Alan Bateman  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> test/jdk/java/util/Properties/StoreReproducibilityTest.java line 137:
> 
>> 135:             final Path tmpFile = Files.createTempFile("8231640", ".props");
>> 136:             storedFiles.add(tmpFile);
>> 137:             final ProcessBuilder processBuilder = ProcessTools.createJavaProcessBuilder(
> 
> ProcessTools.createJavaProcessBuilder came up in another PR because it doesn't prepend the VM and java opts. As all usages of PB are being updated in this test then it makes me wonder if it should be changed to use createTestJvm while you're there.

Actually, I was limiting the change to a single JVM invocation ?
But yes, it is appropriate to replace the invocation. Replaced them all.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15829#discussion_r1333464550

From naoto at openjdk.org  Thu Sep 21 18:51:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 21 Sep 2023 18:51:50 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v3]
In-Reply-To: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
Message-ID: 

> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Use createTestJvm for vm invocation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15829/files
  - new: https://git.openjdk.org/jdk/pull/15829/files/30b0af53..bd786b92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15829&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15829&range=01-02

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15829.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15829/head:pull/15829

PR: https://git.openjdk.org/jdk/pull/15829

From asotona at openjdk.org  Thu Sep 21 19:01:30 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Sep 2023 19:01:30 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

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15837#pullrequestreview-1638517974

From joehw at openjdk.org  Thu Sep 21 19:11:20 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 21 Sep 2023 19:11:20 GMT
Subject: RFR: 8316383: NullPointerException in AbstractSAXParser after
 JDK-8306632 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Fix a NPE. The DTD patch (JDK-8306632) moved initialization to factories, for example, for SAXParser, the SecurityManagers are created in the SAXParserFactory impl and passed on to instances of SAXParsers. The (deprecated) XMLReaderFactory however, instantiates SAXParsers directly, thus without initializing the SecurityManagers. This patch checks the condition and creates them if they have not already been constructed.
> 
> Test: XML tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  fix indentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15828/files
  - new: https://git.openjdk.org/jdk/pull/15828/files/5c414425..711d5e24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15828&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15828&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15828.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15828/head:pull/15828

PR: https://git.openjdk.org/jdk/pull/15828

From joehw at openjdk.org  Thu Sep 21 19:20:47 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 21 Sep 2023 19:20:47 GMT
Subject: Integrated: 8316383: NullPointerException in AbstractSAXParser after
 JDK-8306632
In-Reply-To: 
References: 
Message-ID: 

On Tue, 19 Sep 2023 21:10:41 GMT, Joe Wang  wrote:

> Fix a NPE. The DTD patch (JDK-8306632) moved initialization to factories, for example, for SAXParser, the SecurityManagers are created in the SAXParserFactory impl and passed on to instances of SAXParsers. The (deprecated) XMLReaderFactory however, instantiates SAXParsers directly, thus without initializing the SecurityManagers. This patch checks the condition and creates them if they have not already been constructed.
> 
> Test: XML tests passed.

This pull request has now been integrated.

Changeset: 4e571775
Author:    Joe Wang 
URL:       https://git.openjdk.org/jdk/commit/4e5717754ab3009c75869bf9f228820adb86dd98
Stats:     78 lines in 3 files changed: 65 ins; 10 del; 3 mod

8316383: NullPointerException in AbstractSAXParser after JDK-8306632

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15828

From darcy at openjdk.org  Thu Sep 21 19:26:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 21 Sep 2023 19:26:53 GMT
Subject: RFR: JDK-8316688: Widen allowable error bound of Math.hypot
Message-ID: <7CBst1Ry34RNh_v--gOWkGXyl1bISdzDV9Rp1g4zqmQ=.bf9cf4e6-6c9d-457d-b8c1-54ce2df362fc@github.com>

The Math.hypot method claims its error bound is one ulp.

The paper

"Accuracy of Mathematical Functions in Single, Double, Double
Extended, and Quadruple Precision"
Brian Gladman, Vincenzo Innocente and Paul Zimmermann
September 21, 2023
https://members.loria.fr/PZimmermann/papers/accuracy.pdf

lists a known worst-case error of 1.21 ulps for hypot for the "OpenLibm" math library, which is a derivative of FDLIBM.

The specification of Math.hypot should be updated to acknowledge the wider error bound. I changed the allowable error bound to 1.5 ulps is give a bit of cushion.

-------------

Commit messages:
 - JDK-8316688: Widen allowable error bound of Math.hypot

Changes: https://git.openjdk.org/jdk/pull/15868/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15868&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316688
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15868/head:pull/15868

PR: https://git.openjdk.org/jdk/pull/15868

From darcy at openjdk.org  Thu Sep 21 19:26:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 21 Sep 2023 19:26:54 GMT
Subject: RFR: JDK-8316688: Widen allowable error bound of Math.hypot
In-Reply-To: <7CBst1Ry34RNh_v--gOWkGXyl1bISdzDV9Rp1g4zqmQ=.bf9cf4e6-6c9d-457d-b8c1-54ce2df362fc@github.com>
References: <7CBst1Ry34RNh_v--gOWkGXyl1bISdzDV9Rp1g4zqmQ=.bf9cf4e6-6c9d-457d-b8c1-54ce2df362fc@github.com>
Message-ID: <0fE332usOZa55h80axsXiUhmYN9xXcEmKrlLG5rLtns=.9e8b44cc-fdbb-4225-b4a2-c8408822d420@github.com>

On Thu, 21 Sep 2023 19:19:34 GMT, Joe Darcy  wrote:

> The Math.hypot method claims its error bound is one ulp.
> 
> The paper
> 
> "Accuracy of Mathematical Functions in Single, Double, Double
> Extended, and Quadruple Precision"
> Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> September 21, 2023
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> lists a known worst-case error of 1.21 ulps for hypot for the "OpenLibm" math library, which is a derivative of FDLIBM.
> 
> The specification of Math.hypot should be updated to acknowledge the wider error bound. I changed the allowable error bound to 1.5 ulps is give a bit of cushion.

Please also review the CSR https://bugs.openjdk.org/browse/JDK-8316690

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15868#issuecomment-1730166009

From pchilanomate at openjdk.org  Thu Sep 21 19:34:23 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 21 Sep 2023 19:34:23 GMT
Subject: RFR: 8316456: StackWalker may skip Continuation::yield0 frame
 mistakenly [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 21 Sep 2023 18:20:36 GMT, Mandy Chung  wrote:

>> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
>> stream is currently at the frame decoded in the last patch and so always
>> advances to the next frame before filling in the new batch of stack frame.
>> However `JVM_MoreStackWalk` may return 0.  The library will set 
>> the continuation to its parent. It then call `JVM_MoreStackWalk` to continue
>> the stack walking but the last decoded frame has already been advanced.
>> The Java frame stream is already at the top frame of the parent continuation. .
>> The current implementation skips "Continuation::yield0" mistakenly.  This
>> only happens with `-XX:+ShowHiddenFrames` or `StackWalker.Option.SHOW_HIDDEN_FRAMES`.
>> 
>> The fix is to pass the number of frames decoded in the last batch to `JVM_MoreStackWalk`
>> so that the VM will determine if the current frame should be skipped or not.
>> 
>> `test/jdk/jdk/internal/vm/Continuation/Scoped.java` test now correctly checks
>> the expected result where "yield0" exists between "enter" and "run" frames.
>
> Mandy Chung has updated the pull request with a new target base 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' of https://github.com/openjdk/jdk into JDK-8316456
>  - call setBatch to update origin and fence for an empty batch
>  - 8316456: StackWalker may skip Continuation::yield0 frame mistakenly

Looks good to me, thanks.

Patricio

src/hotspot/share/prims/stackwalk.cpp line 189:

> 187:     // skip hidden frames for default StackWalker option (i.e. SHOW_HIDDEN_FRAMES
> 188:     // not set) and when StackWalker::getCallerClass is called
> 189:     LogTarget(Debug, stackwalk) lt;

Nit, leftover.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15804#pullrequestreview-1638561745
PR Review Comment: https://git.openjdk.org/jdk/pull/15804#discussion_r1333514103

From redestad at openjdk.org  Thu Sep 21 19:35:09 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 21 Sep 2023 19:35:09 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

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15837#pullrequestreview-1638566011

From redestad at openjdk.org  Thu Sep 21 19:35:11 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 21 Sep 2023 19:35:11 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 13:55:18 GMT, Chen Liang  wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 236:
>> 
>>> 234:         private void inflate() {
>>> 235:             int singleBytes = JLA.countPositives(rawBytes, offset, rawLen);
>>> 236:             int hash = ArraysSupport.vectorizedHashCode(rawBytes, offset, singleBytes, 0, ArraysSupport.T_BOOLEAN);
>> 
>> We should keep in mind that this code is on lambdas bootstrap critical path.
>> Any foreign code may involve lambdas or method references and cause dead end in lambdas initialization after JDK-8294960.
>
> This is safe: these two functions are already used in String itself (see StringLatin1) which is definitely loaded and initialized before Classfile API and its implementations are.

Agreed w.r.t bootstrap safety: `countPositives` and `vectorizedHashCode` are straightforward java routines used by `String` and others very early in the bootstrap sequence. The speed-up they bring come from being intrinsified by the JIT.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15837#discussion_r1333516133

From bpb at openjdk.org  Thu Sep 21 19:50:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Sep 2023 19:50:45 GMT
Subject: RFR: JDK-8316688: Widen allowable error bound of Math.hypot
In-Reply-To: <7CBst1Ry34RNh_v--gOWkGXyl1bISdzDV9Rp1g4zqmQ=.bf9cf4e6-6c9d-457d-b8c1-54ce2df362fc@github.com>
References: <7CBst1Ry34RNh_v--gOWkGXyl1bISdzDV9Rp1g4zqmQ=.bf9cf4e6-6c9d-457d-b8c1-54ce2df362fc@github.com>
Message-ID: 

On Thu, 21 Sep 2023 19:19:34 GMT, Joe Darcy  wrote:

> The Math.hypot method claims its error bound is one ulp.
> 
> The paper
> 
> "Accuracy of Mathematical Functions in Single, Double, Double
> Extended, and Quadruple Precision"
> Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> September 21, 2023
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> lists a known worst-case error of 1.21 ulps for hypot for the "OpenLibm" math library, which is a derivative of FDLIBM.
> 
> The specification of Math.hypot should be updated to acknowledge the wider error bound. I changed the allowable error bound to 1.5 ulps is give a bit of cushion.

Approved. CSR also reviewed.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15868#pullrequestreview-1638590617

From mchung at openjdk.org  Thu Sep 21 20:11:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 21 Sep 2023 20:11:12 GMT
Subject: RFR: 8316456: StackWalker may skip Continuation::yield0 frame
 mistakenly [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 21 Sep 2023 19:29:30 GMT, Patricio Chilano Mateo  wrote:

>> Mandy Chung has updated the pull request with a new target base 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' of https://github.com/openjdk/jdk into JDK-8316456
>>  - call setBatch to update origin and fence for an empty batch
>>  - 8316456: StackWalker may skip Continuation::yield0 frame mistakenly
>
> src/hotspot/share/prims/stackwalk.cpp line 189:
> 
>> 187:     // skip hidden frames for default StackWalker option (i.e. SHOW_HIDDEN_FRAMES
>> 188:     // not set) and when StackWalker::getCallerClass is called
>> 189:     LogTarget(Debug, stackwalk) lt;
> 
> Nit, leftover.

Thanks for the review.  Will clean up before it's integrated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15804#discussion_r1333551895

From rgiulietti at openjdk.org  Thu Sep 21 20:44:12 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 21 Sep 2023 20:44:12 GMT
Subject: RFR: JDK-8316688: Widen allowable error bound of Math.hypot
In-Reply-To: <7CBst1Ry34RNh_v--gOWkGXyl1bISdzDV9Rp1g4zqmQ=.bf9cf4e6-6c9d-457d-b8c1-54ce2df362fc@github.com>
References: <7CBst1Ry34RNh_v--gOWkGXyl1bISdzDV9Rp1g4zqmQ=.bf9cf4e6-6c9d-457d-b8c1-54ce2df362fc@github.com>
Message-ID: 

On Thu, 21 Sep 2023 19:19:34 GMT, Joe Darcy  wrote:

> The Math.hypot method claims its error bound is one ulp.
> 
> The paper
> 
> "Accuracy of Mathematical Functions in Single, Double, Double
> Extended, and Quadruple Precision"
> Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> September 21, 2023
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> lists a known worst-case error of 1.21 ulps for hypot for the "OpenLibm" math library, which is a derivative of FDLIBM.
> 
> The specification of Math.hypot should be updated to acknowledge the wider error bound. I changed the allowable error bound to 1.5 ulps is give a bit of cushion.

Marked as reviewed by rgiulietti (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15868#pullrequestreview-1638670049

From jlu at openjdk.org  Thu Sep 21 21:34:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Sep 2023 21:34:22 GMT
Subject: Integrated: JDK-8316435: sun.util.calendar.CalendarSystem subclassing
 should be restricted
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 22:42:09 GMT, Justin Lu  wrote:

> Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations. Drive by cleanup included.
> 
> As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (`JulianCalendar.Date` must now have package visibility).
> 
> 
> This system has the following structure,
> 
> `CalendarSystem` extended by `AbstractCalendar` extended by `BaseCalendar` extended by 
> (`Gregorian, JulianCalendar, LocalGregorianCalendar`)
> 
> `CalendarDate` extended by `BaseCalendar.Date` extended by 
> (`Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date`)
> 
> Additionally, CalendarUtils was made `final`, as it is a utility class composed of static util methods.

This pull request has now been integrated.

Changeset: 496264c1
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/496264c1f98d313f3df19f919b54c98fc03d88f7
Stats:     149 lines in 9 files changed: 101 ins; 7 del; 41 mod

8316435: sun.util.calendar.CalendarSystem subclassing should be restricted

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15803

From jlu at openjdk.org  Thu Sep 21 21:34:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Sep 2023 21:34:22 GMT
Subject: Integrated: JDK-8316629: j.text.DateFormatSymbols setZoneStrings()
 exception is unhelpful
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 22:10:16 GMT, Justin Lu  wrote:

> Please review this PR, which updates the exception message for java.text.DateFormatSymbols.setZoneStrings
> 
> `setZoneStrings()` takes a multi dimensional array as input. If any row does not have a length of at least 5, an _IllegalArgumentException_ is thrown. The exception should indicate why it was thrown.

This pull request has now been integrated.

Changeset: ef49e6c0
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/ef49e6c0d7e4e3a2d7d3d8dcb1edf195b23ce12c
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8316629: j.text.DateFormatSymbols setZoneStrings() exception is unhelpful

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15849

From duke at openjdk.org  Thu Sep 21 22:04:14 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 21 Sep 2023 22:04:14 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float)
In-Reply-To: 
References: 
Message-ID: 

On Thu, 21 Sep 2023 12:51:56 GMT, Raffaello Giulietti  wrote:

> 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.

These constant names should be?in?uppercase:

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 110:

> 108:     private static final int NAN            = 5;
> 109: 
> 110:     private static final JavaLangAccess jla = SharedSecrets.getJavaLangAccess();

Suggestion:

    private static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();

src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java line 110:

> 108:     private static final int NAN            = 5;
> 109: 
> 110:     private static final JavaLangAccess jla = SharedSecrets.getJavaLangAccess();

Suggestion:

    private static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();

-------------

PR Review: https://git.openjdk.org/jdk/pull/15861#pullrequestreview-1638247433
PR Review Comment: https://git.openjdk.org/jdk/pull/15861#discussion_r1333314116
PR Review Comment: https://git.openjdk.org/jdk/pull/15861#discussion_r1333316192

From naoto at openjdk.org  Thu Sep 21 22:47:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 21 Sep 2023 22:47:16 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 23:20:43 GMT, Justin Lu  wrote:

> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
> 
> Any files named BugXXXXXXX.java will be renamed after review.

test/jdk/java/util/Calendar/Bug4766302.java line 32:

> 30: import java.util.GregorianCalendar;
> 31: 
> 32: @SuppressWarnings("serial")

Is removing this OK?

test/jdk/java/util/Calendar/bug4028518.java line 41:

> 39: public class bug4028518 {
> 40: 
> 41:     // Ensure modifying cloned gregCalendar does not modify the original

Seems that the comment is saying the other way around

test/jdk/java/util/Calendar/bug4243802.java line 48:

> 46:     void setUp() {
> 47:         Locale.setDefault(Locale.US);
> 48:         TimeZone.setDefault(TimeZone.getTimeZone("America/Los_Angeles"));

If the test is not going to restore the original defaults with `tearDown()`, I'd expect `othervm` explicitly on `@run` directive. (applies to other locations)

test/jdk/java/util/Calendar/bug4316678.java line 58:

> 56:     @Test
> 57:     public void serializationTest() throws IOException, ClassNotFoundException {
> 58:         TimeZone.setDefault(TimeZone.getTimeZone("PST"));

Not needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1333653061
PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1333655945
PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1333663335
PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1333665846

From duke at openjdk.org  Thu Sep 21 22:58:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 21 Sep 2023 22:58:17 GMT
Subject: Integrated: 8316582: Minor startup regression in 22-b15 due
 JDK-8310929
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 09:12:48 GMT, Claes Redestad  wrote:

> This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`. 
> 
> This use is the cause of a small (~1.5ms) startup regression in 22-b15. While a manageable startup regression in and of itself, the use of `VarHandles` in core utility classes brings an increased risk of bootstrap circularity issues, for example disqualifying the use of things like `Integers.toString` in some places.
> 
> Reverting this partially rolls back the performance improvement gained by JDK-8310929. It seems reasonable that the compiler can be enhanced to gain that loss back.

digitPair and Unsafe.putShort are a good combination. Can Unsafe be used here?


   public static void writeDigitPair(byte[] buf, int charPos, int value) {
        Unsafe.putShortUnaligned(
                buf,
                Unsafe.ARRAY_BYTE_BASE_OFFSET + pos,
                digitPair(value),
                false);
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15836#issuecomment-1730456039

From redestad at openjdk.org  Thu Sep 21 23:12:27 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 21 Sep 2023 23:12:27 GMT
Subject: Integrated: 8316582: Minor startup regression in 22-b15 due
 JDK-8310929
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 09:12:48 GMT, Claes Redestad  wrote:

> This patch reverts the use of `ByteArrayLittleEndian` in `StringLatin1`. 
> 
> This use is the cause of a small (~1.5ms) startup regression in 22-b15. While a manageable startup regression in and of itself, the use of `VarHandles` in core utility classes brings an increased risk of bootstrap circularity issues, for example disqualifying the use of things like `Integers.toString` in some places.
> 
> Reverting this partially rolls back the performance improvement gained by JDK-8310929. It seems reasonable that the compiler can be enhanced to gain that loss back.

I'd like us to take a step back and instead of reaching for and sprinkling `Unsafe`, `ByteArrayLittleEndian` and `VarHandles` all over the place to instead consider differences in performance on trivial code like this as compiler bugs. We need to investigate if there's anything we can do to have the JIT generate better code here for idiomatic java, and only once we thoroughly understand if and why that's not possible to reach for other options.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15836#issuecomment-1730469964

From mchung at openjdk.org  Thu Sep 21 23:16:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 21 Sep 2023 23:16:04 GMT
Subject: RFR: 8316456: StackWalker may skip Continuation::yield0 frame
 mistakenly [v3]
In-Reply-To: 
References: 
Message-ID: 

> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
> stream is currently at the frame decoded in the last patch and so always
> advances to the next frame before filling in the new batch of stack frame.
> However `JVM_MoreStackWalk` may return 0.  The library will set 
> the continuation to its parent. It then call `JVM_MoreStackWalk` to continue
> the stack walking but the last decoded frame has already been advanced.
> The Java frame stream is already at the top frame of the parent continuation. .
> The current implementation skips "Continuation::yield0" mistakenly.  This
> only happens with `-XX:+ShowHiddenFrames` or `StackWalker.Option.SHOW_HIDDEN_FRAMES`.
> 
> The fix is to pass the number of frames decoded in the last batch to `JVM_MoreStackWalk`
> so that the VM will determine if the current frame should be skipped or not.
> 
> `test/jdk/jdk/internal/vm/Continuation/Scoped.java` test now correctly checks
> the expected result where "yield0" exists between "enter" and "run" frames.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  minor clean up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15804/files
  - new: https://git.openjdk.org/jdk/pull/15804/files/ddaeaf99..14f13223

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15804&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15804&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15804/head:pull/15804

PR: https://git.openjdk.org/jdk/pull/15804

From mchung at openjdk.org  Thu Sep 21 23:16:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 21 Sep 2023 23:16:05 GMT
Subject: Integrated: 8316456: StackWalker may skip Continuation::yield0 frame
 mistakenly
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 23:00:09 GMT, Mandy Chung  wrote:

> `JVM_MoreStackWalk` has a bug that always assumes that the Java frame
> stream is currently at the frame decoded in the last patch and so always
> advances to the next frame before filling in the new batch of stack frame.
> However `JVM_MoreStackWalk` may return 0.  The library will set 
> the continuation to its parent. It then call `JVM_MoreStackWalk` to continue
> the stack walking but the last decoded frame has already been advanced.
> The Java frame stream is already at the top frame of the parent continuation. .
> The current implementation skips "Continuation::yield0" mistakenly.  This
> only happens with `-XX:+ShowHiddenFrames` or `StackWalker.Option.SHOW_HIDDEN_FRAMES`.
> 
> The fix is to pass the number of frames decoded in the last batch to `JVM_MoreStackWalk`
> so that the VM will determine if the current frame should be skipped or not.
> 
> `test/jdk/jdk/internal/vm/Continuation/Scoped.java` test now correctly checks
> the expected result where "yield0" exists between "enter" and "run" frames.

This pull request has now been integrated.

Changeset: c72f0046
Author:    Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/c72f00463fcb1c4a94126932abbc82a2582c10c2
Stats:     210 lines in 7 files changed: 47 ins; 57 del; 106 mod

8316456: StackWalker may skip Continuation::yield0 frame mistakenly

Reviewed-by: rpressler, pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/15804

From mchung at openjdk.org  Thu Sep 21 23:28:28 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 21 Sep 2023 23:28:28 GMT
Subject: RFR: 8316305: Initial buffer size of StackWalker is too small
 caused by JDK-8285447 [v2]
In-Reply-To: 
References: 
Message-ID: 

> A trivial fix.   [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) intends to change the initial batch size only for a stack walker with an estimated stack depth. For stack walkers without user-supplied estimated stack depth, the initial batch size is changed to 3 which is a bug.  This causes the stack walker to fetch the second batch after walking 2 frames.

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Fix a warning caused by 8316456
 - Merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8316305
 - 8316305: Initial buffer size of StackWalker is too small caused by JDK-8285447

-------------

Changes: https://git.openjdk.org/jdk/pull/15749/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15749&range=01
  Stats: 9 lines in 2 files changed: 1 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15749/head:pull/15749

PR: https://git.openjdk.org/jdk/pull/15749

From duke at openjdk.org  Thu Sep 21 23:43:17 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 21 Sep 2023 23:43:17 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>
 
 
Message-ID: 

On Thu, 21 Sep 2023 07:43:47 GMT, iaroslavski  wrote:

>> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comments (v23.08)
>
>> Hi Vladimir,
>> 
>> Just trying to understand: is there a reason to use `DualPivotQuicksort_RadixForParallel.java` and `DualPivotQuicksort_RadixForAll.java`?
>> 
>> Would it not be sufficient to do the following two runs:
>> 
>> 1. Baseline (Stock JDK) vs. AVX512 sort for`sort()`and `parallelSort()` ?
>> 2. AVX512 sort vs. Radix sort for `sort()` and `parallelSort()` ?
>> 
>> Thanks, Vamsi
> 
> Hi Vamsi (@vamsi-parasa)!
> 
> I appreciate if you kindly agree to help with perf runs on your environment.
> Results from your runs will help us to detect the impact of Radix sort in *vectorized* sorting, this is very important topic.
> 
> Interesting comparisons are:
> 
> 1. AVX512 sort (your implementation) vs. DualPivotQuicksort_RadixForParallel (contains AVX512 + radix for parallel sort)
>     https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForParallel.java
> 
> 2. AVX512 sort (your implementation) vs. DualPivotQuicksort_RadixForAll (contains AVX512 + radix for all)
>     https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForAll.java
> 
> If you add the 3-rd comparison
> baseline (stock JDK) vs. AVX512 sort - it would be great also!
> 
> Please use this JMH test to run on:
> 
> * all sizes
> * all inputs
> * int type only
> * sort() and parallelSort()
> 
> https://github.com/openjdk/jdk/blob/42e17e45b1adc4d77ba5549770ce591d96d4b1fe/test/micro/org/openjdk/bench/java/util/ArraysSort.java
> 
> Looking forward the results,
> Vladimir

Hi Vladimir (@iaroslavski),

Kindly give me some time to do the JMH performance runs as I am currently occupied with various tasks related to the closing of the AVX512 sort PR.

Thanks,
Vamsi

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1730493823

From mchung at openjdk.org  Thu Sep 21 23:50:36 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 21 Sep 2023 23:50:36 GMT
Subject: RFR: 8316305: Initial buffer size of StackWalker is too small
 caused by JDK-8285447 [v3]
In-Reply-To: 
References: 
Message-ID: 

> A trivial fix.   [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) intends to change the initial batch size only for a stack walker with an estimated stack depth. For stack walkers without user-supplied estimated stack depth, the initial batch size is changed to 3 which is a bug.  This causes the stack walker to fetch the second batch after walking 2 frames.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Revert this change. PR 15876

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15749/files
  - new: https://git.openjdk.org/jdk/pull/15749/files/6cd1d09d..67971b46

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15749&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15749&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15749/head:pull/15749

PR: https://git.openjdk.org/jdk/pull/15749

From duke at openjdk.org  Fri Sep 22 02:02:40 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 22 Sep 2023 02:02:40 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v40]
In-Reply-To: 
References: 
 
 
Message-ID: <-eF1UnML64gT7J2ZpfBLoE9MNl5n_J5JPR8dSPqzN5Y=.19454765-4b68-459b-b487-3193ceea4eda@github.com>

On Thu, 21 Sep 2023 16:44:52 GMT, Paul Sandoz  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change variable names of indexPivot* to pivotIndex*
>
> test/jdk/java/util/Arrays/Sorting.java line 30:
> 
>> 28:  * @build Sorting
>> 29:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySort,_arrayPartition, Sorting -shortrun
>> 30:  * @run main/othervm -XX:CompileThreshold=1 -XX:-TieredCompilation Sorting -shortrun
> 
> It would be useful to target the compilation threshold only for the intrinsic methods, but i suspect that is not possible?

Hi Paul,

Did some further study and found that it's possible to scale the compilation threshold only for the intrinsic methods (`sort `and `partition`)  using the `CompileCommand` and `CompileThersholdScaling` 

 ``` 
-XX:-TieredCompilation -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::sort,0.0001  -XX:CompileCommand=CompileThresholdScaling,java.util.DualPivotQuicksort::partition,0.0001


Will push this change along with build script change suggested by Magnus.

Thanks,
Vamsi

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1333797193

From duke at openjdk.org  Fri Sep 22 02:28:40 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 02:28:40 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
Message-ID: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@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:
 - shared between Formatter and FormatProcessor
 - refactor & bug fix
 - refactor
 - bug fix for '%T' not throw error
 - bug fix
 - drop the regex code entirely and write a custom parser
 - fix specifiers duplicate flags not throw error
 - fix specifiers support '%
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
Message-ID: 

On Sun, 17 Sep 2023 16:01:33 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)

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 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"?

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"

-------------

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1630133740
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1728424181
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1730173405
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1328152682

From duke at openjdk.org  Fri Sep 22 02:28:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 02:28:41 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
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: 

On Sun, 17 Sep 2023 16:01:33 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)

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1723733247
PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1730164585

From duke at openjdk.org  Fri Sep 22 02:28:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 02:28:41 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: <77B3TKxbzlcIaGWA6eW7qM09-JsCHWoAOZKDOF3HYwY=.72f6ff18-f7dd-4ba5-90f8-0d5e781a26c1@github.com>

On Sun, 17 Sep 2023 22:16:08 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 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_r1328178751

From duke at openjdk.org  Fri Sep 22 02:28:41 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 02:28:41 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: <77B3TKxbzlcIaGWA6eW7qM09-JsCHWoAOZKDOF3HYwY=.72f6ff18-f7dd-4ba5-90f8-0d5e781a26c1@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
 <77B3TKxbzlcIaGWA6eW7qM09-JsCHWoAOZKDOF3HYwY=.72f6ff18-f7dd-4ba5-90f8-0d5e781a26c1@github.com>
Message-ID: 

On Mon, 18 Sep 2023 00:48:26 GMT, ???  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 redestad at openjdk.org  Fri Sep 22 02:28:41 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 22 Sep 2023 02:28:41 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
 <77B3TKxbzlcIaGWA6eW7qM09-JsCHWoAOZKDOF3HYwY=.72f6ff18-f7dd-4ba5-90f8-0d5e781a26c1@github.com>
 
Message-ID: 

On Mon, 18 Sep 2023 02:59:06 GMT, ???  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 liach at openjdk.org  Fri Sep 22 03:56:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 03:56:10 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v3]
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 163 commits:

 - Post-merge cleanup
 - Merge branch 'pr/15103' of https://github.com/openjdk/jdk into cleanup/vh-template-share
 - byte array var handles can share a common base class
 - Clean up VarHandle template classes
 - 8316229: Enhance class initialization logging
   
   Reviewed-by: shade, coleenp
 - 8316627: JViewport Test headless failure
   
   Reviewed-by: dcubed, prr
 - 8316156: ByteArrayInputStream.transferTo causes MaxDirectMemorySize overflow
   
   Reviewed-by: alanb
 - 8316532: Native library copying in BuildMicrobenchmark.gmk cause dups on macOS
   
   Reviewed-by: ihse, redestad
 - 8315869: UseHeavyMonitors not used
   
   Reviewed-by: dcubed, alanb
 - 8316562: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java times out after JDK-8314829
   
   Reviewed-by: dholmes, kevinw, dcubed
 - ... and 153 more: https://git.openjdk.org/jdk/compare/1f3248df...f291cabb

-------------

Changes: https://git.openjdk.org/jdk/pull/15854/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=02
  Stats: 68704 lines in 1907 files changed: 21583 ins; 14286 del; 32835 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 liach at openjdk.org  Fri Sep 22 03:58:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 03:58:24 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 21 Sep 2023 08:50:00 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:
> 
>   byte array var handles can share a common base class

Since this cleanup affects both non-ffi and ffi VHs, I have re-targeted this against the FFI JEP pr. The only issue is that this pr now includes the mainline changes so the diff is probably not reviewable until the JEP pr's merged.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15854#issuecomment-1730766746

From duke at openjdk.org  Fri Sep 22 04:10:26 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 04:10:26 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v5]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: <2DjDwX78G-DBY860dUc1nrH989pG9sOmu9owZOdnl8k=.0bab6d6d-d5f0-4d92-9569-675edd967014@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

??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - rebase from master & refactor digits
 - rebase from master
 - Merge remote-tracking branch 'upstream/master' into refactor_get_chars_and_string_size
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/StringLatin1.java
 - add comment
 - fix build error
 - fix build error
 - move StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1
 - move *::stringSize to jdk.internal.util.DecimalDigits::stringSize

-------------

Changes: https://git.openjdk.org/jdk/pull/15699/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=04
  Stats: 516 lines in 12 files changed: 149 ins; 280 del; 87 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 liach at openjdk.org  Fri Sep 22 04:49:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 04:49:21 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v5]
In-Reply-To: <2DjDwX78G-DBY860dUc1nrH989pG9sOmu9owZOdnl8k=.0bab6d6d-d5f0-4d92-9569-675edd967014@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 <2DjDwX78G-DBY860dUc1nrH989pG9sOmu9owZOdnl8k=.0bab6d6d-d5f0-4d92-9569-675edd967014@github.com>
Message-ID: 

On Fri, 22 Sep 2023 04:10:26 GMT, ???  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
>
> ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - rebase from master & refactor digits
>  - rebase from master
>  - Merge remote-tracking branch 'upstream/master' into refactor_get_chars_and_string_size
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/StringLatin1.java
>  - add comment
>  - fix build error
>  - fix build error
>  - move StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1
>  - move *::stringSize to jdk.internal.util.DecimalDigits::stringSize

Do Octal and Hex digits need int versions of getChars and stringSize?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1730795452

From duke at openjdk.org  Fri Sep 22 05:32:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 05:32:10 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v5]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 <2DjDwX78G-DBY860dUc1nrH989pG9sOmu9owZOdnl8k=.0bab6d6d-d5f0-4d92-9569-675edd967014@github.com>
 
Message-ID: <1qNVgUp0u_o1hLOC4qWxrAzIAOs3hXU9X2fhIujZxiQ=.7d200317-2f1c-4fca-890c-b366beeedb62@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 liach at openjdk.org  Fri Sep 22 05:42:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 05:42:17 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v5]
In-Reply-To: <2DjDwX78G-DBY860dUc1nrH989pG9sOmu9owZOdnl8k=.0bab6d6d-d5f0-4d92-9569-675edd967014@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 <2DjDwX78G-DBY860dUc1nrH989pG9sOmu9owZOdnl8k=.0bab6d6d-d5f0-4d92-9569-675edd967014@github.com>
Message-ID: 

On Fri, 22 Sep 2023 04:10:26 GMT, ???  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
>
> ??? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - rebase from master & refactor digits
>  - rebase from master
>  - Merge remote-tracking branch 'upstream/master' into refactor_get_chars_and_string_size
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/StringLatin1.java
>  - add comment
>  - fix build error
>  - fix build error
>  - move StringLatin1::getChars to jdk.internal.util.DecimalDigits::getCharsLatin1
>  - move *::stringSize to jdk.internal.util.DecimalDigits::stringSize

Changes requested by liach (Author).

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

-------------

PR Review: https://git.openjdk.org/jdk/pull/15699#pullrequestreview-1639167213
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1333894410
PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1333894660

From darcy at openjdk.org  Fri Sep 22 05:42:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 22 Sep 2023 05:42:23 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:
 - 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: 31 lines in 1 file changed: 30 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  Fri Sep 22 05:42:24 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 22 Sep 2023 05:42:24 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 alanb at openjdk.org  Fri Sep 22 06:19:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 22 Sep 2023 06:19:11 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v3]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
Message-ID: <-OLCeKM67o62Op4RCKb2NihGkt0LMgo5PkYrWpVGiAA=.6644ab2a-f107-4c6d-bd5d-275e2905bb8f@github.com>

On Thu, 21 Sep 2023 18:51:50 GMT, Naoto Sato  wrote:

>> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use createTestJvm for vm invocation

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15829#pullrequestreview-1639214386

From alanb at openjdk.org  Fri Sep 22 06:19:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 22 Sep 2023 06:19:12 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v2]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
 
 
Message-ID: 

On Thu, 21 Sep 2023 18:35:57 GMT, Naoto Sato  wrote:

> But yes, it is appropriate to replace the invocation. Replaced them all.

Thanks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15829#discussion_r1333926851

From aturbanov at openjdk.org  Fri Sep 22 06:47:12 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 22 Sep 2023 06:47:12 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit
In-Reply-To: 
References: 
Message-ID: <_8mFOdsLmNXEdsF_B3MooAsKrZUo2TsiBjkxWAfXEmY=.6081fd06-277e-4485-9de1-6b68fe94b80b@github.com>

On Wed, 20 Sep 2023 23:20:43 GMT, Justin Lu  wrote:

> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
> 
> Any files named BugXXXXXXX.java will be renamed after review.

test/jdk/java/util/Calendar/BuddhistCalendarTest.java line 141:

> 139:     @Test
> 140:     public void buddhistSetTest() {
> 141:         Calendar cal  = getBuddhistCalendar();

Suggestion:

        Calendar cal = getBuddhistCalendar();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1333947857

From jpai at openjdk.org  Fri Sep 22 07:08:14 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 22 Sep 2023 07:08:14 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v3]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
Message-ID: 

On Thu, 21 Sep 2023 18:51:50 GMT, Naoto Sato  wrote:

>> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use createTestJvm for vm invocation

The difference between `createJavaProcessBuilder()` and `createTestJvm()` appears to be that additionally `test.vm.opts` and `test.java.opts` system properties get prefixed to the opts that are passed for the process creation. That looks fine to me, for this test. 

The current state of this PR in `bd786b92` looks good to me. Thank you Naoto for the updates.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15829#pullrequestreview-1639276171

From duke at openjdk.org  Fri Sep 22 07:19:27 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 07:19:27 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v6]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  restore HexDigits & OctalDigits

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/c0394e03..91db6031

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=04-05

  Stats: 134 lines in 4 files changed: 70 ins; 39 del; 25 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 duke at openjdk.org  Fri Sep 22 08:22:12 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 22 Sep 2023 08:22:12 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v6]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 07:19:27 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore HexDigits & OctalDigits

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);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1334053601

From liach at openjdk.org  Fri Sep 22 08:45:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 08:45:13 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 18:09:57 GMT, Mourad Abbay  wrote:

> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.

What is this patch looking to fix? The link is not broken in the first place. This `#mapMulti mapMulti` aims to hide the irrelevant long list of parameter types Javadoc renders, like that seen in [`flatMap`'s](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Stream.html#flatMap(java.util.function.Function)) "See Also" section.

I believe a simple `mapMulti` is better than an overblown `mapMulti(java.util.function.BiConsumer>)`. However, it's always better to unify the rendering in both cases, such as updating the link in `flatMap`'s `@see` to `@see #mapMulti mapMulti`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15794#issuecomment-1731043606

From redestad at openjdk.org  Fri Sep 22 08:47:19 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 22 Sep 2023 08:47:19 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
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: 

On Sun, 17 Sep 2023 16:01:33 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)

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)

-------------

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1639452604

From duke at openjdk.org  Fri Sep 22 09:22:04 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 09:22:04 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  restore HexDigits & OctalDigits

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/91db6031..97c7f025

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Fri Sep 22 10:13:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 10:13:11 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers
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: 

On Sun, 17 Sep 2023 16:01:33 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)

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)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1731163579

From duke at openjdk.org  Fri Sep 22 11:03:12 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Fri, 22 Sep 2023 11:03:12 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 08:42:39 GMT, Chen Liang  wrote:

>> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.
>
> What is this patch looking to fix? The link is not broken in the first place. This `#mapMulti mapMulti` aims to hide the irrelevant long list of parameter types Javadoc renders, like that seen in [`flatMap`'s](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Stream.html#flatMap(java.util.function.Function)) "See Also" section.
> 
> I believe a simple `mapMulti` is better than an overblown `mapMulti(java.util.function.BiConsumer>)`. However, it's always better to unify the rendering in both cases, such as updating the link in `flatMap`'s `@see` to `@see #mapMulti mapMulti`.

@liach here the result of having `@see #mapMulti mapMulti`
Screenshot 2023-09-22 at 11 57 44 AM

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15794#issuecomment-1731226664

From pminborg at openjdk.org  Fri Sep 22 11:08:16 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 22 Sep 2023 11:08:16 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v3]
In-Reply-To: <8Y_HVJGTPU6vuu1YlwLrHJvAzNCTekesg6eSmGZu3QI=.5ff02864-ec82-4c2a-a21a-13d987852ff9@github.com>
References: 
 <8Y_HVJGTPU6vuu1YlwLrHJvAzNCTekesg6eSmGZu3QI=.5ff02864-ec82-4c2a-a21a-13d987852ff9@github.com>
Message-ID: 

On Thu, 21 Sep 2023 16:40:59 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 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

Looking at the potential compatibility issues (See CSR), I have produced an alternate draft PR that solves the problem by simply not overriding `AbstractMap`: https://github.com/openjdk/jdk/pull/15887

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-1731232410

From liach at openjdk.org  Fri Sep 22 11:09:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 11:09:08 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti
In-Reply-To: 
References: 
Message-ID: <59elVWYNos0UI4znVmWCzDrcWX0dze1XBpbavYKZ_mQ=.109843e3-df90-48c0-a188-b0b2a1a25e5b@github.com>

On Mon, 18 Sep 2023 18:09:57 GMT, Mourad Abbay  wrote:

> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.

Then it's a bug with Intellij IDEA not able to parse these links correctly. It should be fixed in their open source repository at https://github.com/JetBrains/intellij-community instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15794#issuecomment-1731233937

From liach at openjdk.org  Fri Sep 22 11:19:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 11:19:12 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v3]
In-Reply-To: <8Y_HVJGTPU6vuu1YlwLrHJvAzNCTekesg6eSmGZu3QI=.5ff02864-ec82-4c2a-a21a-13d987852ff9@github.com>
References: 
 <8Y_HVJGTPU6vuu1YlwLrHJvAzNCTekesg6eSmGZu3QI=.5ff02864-ec82-4c2a-a21a-13d987852ff9@github.com>
Message-ID: 

On Thu, 21 Sep 2023 16:40:59 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 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

For compatibility, the alternative is arguably dangerous too: Users could cast the factories map to AbstractMap, a public type, before, and that may be another impl detail that they accidentally depend on. And legacy user immutable maps may have a harder time migrating to be value classes.

For the current approach, I think this allows existing AbstractMap-based implememtations to go value, which is a great benefit. The risk from the 2 method usages are actually less worrying considering that any subclass that overrides either method will have no compatibility risk. The bigger risk lies in behavioral changes in JDK's builtin Maps' two methods' implementation (loss of caching): I anticipate many more users to actually use than implement maps. Another less pronounced risk is users reflecting on the 2 fields, which arguably is low impact for they are technically implementation details.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-1731246046

From liach at openjdk.org  Fri Sep 22 11:40:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 11:40:19 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 09:22:04 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore HexDigits & OctalDigits

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15699#discussion_r1334265520

From duke at openjdk.org  Fri Sep 22 11:59:26 2023
From: duke at openjdk.org (wickund)
Date: Fri, 22 Sep 2023 11:59:26 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: <9bxc1uJ5BM5Njd3wJyOwQn_jvMtVdTlVF3XEFvQiEZI=.f7b63386-19da-4c37-a95b-487d9708af0a@github.com>

On Fri, 22 Sep 2023 09:22:04 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore HexDigits & OctalDigits

Changes requested by wickund at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15699#pullrequestreview-1639806273

From duke at openjdk.org  Fri Sep 22 11:59:27 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Fri, 22 Sep 2023 11:59:27 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 09:22:04 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore HexDigits & OctalDigits

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 jlaskey at openjdk.org  Fri Sep 22 12:13:15 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 22 Sep 2023 12:13:15 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
 
Message-ID: 

On Fri, 22 Sep 2023 11:37:18 GMT, Chen Liang  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore HexDigits & OctalDigits
>
> 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 jlaskey at openjdk.org  Fri Sep 22 12:13:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 22 Sep 2023 12:13:12 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 09:22:04 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore HexDigits & OctalDigits

Changes requested by jlaskey (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15699#pullrequestreview-1639826354

From egahlin at openjdk.org  Fri Sep 22 13:06:34 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 22 Sep 2023 13:06:34 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: 
References: 
 
Message-ID: <5tdptBPPCTyNYn8wbZ1_bN52j8C-YRkWpmMksczutQs=.2700421a-3722-4d42-b186-482e38dba8d7@github.com>

On Tue, 19 Sep 2023 15:35:11 GMT, Tim Prinzing  wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into JDK-8308995
>  - More changes from review:
>    
>    I didn't like the name of the helper method 'checkForCommit' because it
>    doesn't indicate that it might commit the event.  I also don't like
>    'commitEvent' because it might not.  Since JFR events are sort of like a
>    queue I went with a name from collections and called it 'offer' so using
>    it is something like 'SocketReadEvent.offer(...)' which seems like it
>    gets the idea across better.  Also improved the javadoc for it.
>    
>    Removed the comments about being instrumented by JFR in
>    Socket.SocketInputStream and Socket.SocketOutputStream.
>    
>    I went ahead and moved the event commiting out of the finally block so
>    that we don't emit events when the read/write did not actually happen.
>    The bugid JDK-8310979 will be used to determine if more should be done
>    in this area.
>    
>    The implRead and implWrite were moved up with the other support methods
>    for read/write.
>  - less exception filtering when fetching socket read timeout
>  - remove unused SOCKET_READ and SOCKET_WRITE configurations.
>  - Merge branch 'master' into JDK-8308995
>    
>    # Conflicts:
>    #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
>  - Avoid exceptions getting address/timeout for jfr event. Remove unused
>    EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
>    whitespace.
>  - some changes from review.
>    
>    read0() to implRead()
>    write0() to implWrite()
>    trailing whitespace
>  - fix copyright date
>  - Added micro benchmark to measure socket event overhead.
>  - Some changes from review.
>    
>    Append a 0 to method names being wrapped.  Use getHostString to avoid
>    a reverse lookup when fetching the hostname of the remote address.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/607bd4ed...6db6fab4

The new implementation calls getSocketRemoteAddress() and getSOTimeout() regardless if the event duration exceeds the threshold or not. This adds unnecessary overhead. Most socket write/reads are not committed, only those that take more than 20 ms (by default). I think you need something like this:

if (SocketRead.shouldCommit(...)) {
  ...
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1731379349

From mcimadamore at openjdk.org  Fri Sep 22 13:44:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 13:44:20 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
Message-ID: 

On Mon, 18 Sep 2023 14:17:30 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:
> 
>   Avoid eager use of LibFallback in FallbackLinker static block

src/java.base/share/classes/java/lang/foreign/Linker.java line 152:

> 150:  * 

> 151:  * The following table shows some examples of how C types are modelled in Linux/x64 according to the
> 152:  * "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (all the examples provided

I have seen some discussion on this and I agree an authoritative link does not exist (I have searched for it in the past). I guess I'm not super wild about also including "AMD64 Architecture Processor Supplement". E.g. IMHO "System V Application Binary Interface" is more than enough?

src/java.base/share/classes/java/lang/foreign/Linker.java line 409:

> 407:  *
> 408:  * Variadic functions are C functions which can accept a variable number and type of arguments. They are declared with a
> 409:  * trailing ellipsis ({@code ...}) at the end of the formal parameter list, such as: {@code void foo(int x, ...);}.

Looking at the javadoc - it seems to me that the `;` after the declaration of `foo` leads to a bit of jarring as it is immediately followed by a period (`.`). Consider dropping that - or maybe put the declaration in a snippet.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334395919
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334399541

From duke at openjdk.org  Fri Sep 22 13:53:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 13:53:13 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
 
Message-ID: 

On Fri, 22 Sep 2023 11:53:18 GMT, Andriy Plokhotnyuk  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore HexDigits & OctalDigits
>
> 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 duke at openjdk.org  Fri Sep 22 13:59:11 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Fri, 22 Sep 2023 13:59:11 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti
In-Reply-To: <59elVWYNos0UI4znVmWCzDrcWX0dze1XBpbavYKZ_mQ=.109843e3-df90-48c0-a188-b0b2a1a25e5b@github.com>
References: 
 <59elVWYNos0UI4znVmWCzDrcWX0dze1XBpbavYKZ_mQ=.109843e3-df90-48c0-a188-b0b2a1a25e5b@github.com>
Message-ID: 

On Fri, 22 Sep 2023 11:06:13 GMT, Chen Liang  wrote:

>> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.
>
> Then it's a bug with Intellij IDEA not able to parse these links correctly. It should be fixed in their open source repository at https://github.com/JetBrains/intellij-community instead.

@liach I see, thanks for the review. Should I open a new PR to unify the rendering?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15794#issuecomment-1731467686

From mcimadamore at openjdk.org  Fri Sep 22 14:06:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 14:06:20 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
Message-ID: 

On Mon, 18 Sep 2023 14:17:30 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:
> 
>   Avoid eager use of LibFallback in FallbackLinker static block

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 310:

> 308: 
> 309:     /**
> 310:      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byteSize()} of

Suggestion:

     * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byte size} of

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334428574

From liach at openjdk.org  Fri Sep 22 14:11:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 14:11:23 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 18:09:57 GMT, Mourad Abbay  wrote:

> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.

I recommend just work in the same PR and change all `@see #mapMulti` to `@see #mapMulti mapMulti` and `@see #flatMap` to `@see #flatMap flatMap`. This is how our current link conventions are like: https://github.com/openjdk/jdk/blob/c90d63105ca774c047d5f5a4348aa657efc57953/src/java.base/share/classes/java/util/LinkedHashSet.java#L42

I've already updated the Java Bug System issue for you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15794#issuecomment-1731487532

From mcimadamore at openjdk.org  Fri Sep 22 14:14:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 14:14:19 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 14:03:52 GMT, Maurizio Cimadamore  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid eager use of LibFallback in FallbackLinker static block
>
> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 310:
> 
>> 308: 
>> 309:     /**
>> 310:      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byteSize()} of
> 
> Suggestion:
> 
>      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byte size} of

Also, in the panama repo I see this:

Allocates a memory segment with the given layout and initializes it with the bytes in the provided source memory segment.

Which seems more correct - e.g. more consistent with other allocation methods, and also more succinct (note that the first sentence is really what shows up in the method summary javadoc, so there is a certain interest in providing a quick description of what the method does,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334434230

From mcimadamore at openjdk.org  Fri Sep 22 14:14:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 14:14:20 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
 
Message-ID: 

On Fri, 22 Sep 2023 14:08:29 GMT, Maurizio Cimadamore  wrote:

>> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 310:
>> 
>>> 308: 
>>> 309:     /**
>>> 310:      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byteSize()} of
>> 
>> Suggestion:
>> 
>>      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byte size} of
>
> Also, in the panama repo I see this:
> 
> Allocates a memory segment with the given layout and initializes it with the bytes in the provided source memory segment.
> 
> Which seems more correct - e.g. more consistent with other allocation methods, and also more succinct (note that the first sentence is really what shows up in the method summary javadoc, so there is a certain interest in providing a quick description of what the method does,

Panama repo change:
https://github.com/openjdk/panama-foreign/commit/06e2017883c939188103c4dd53185417a00b2921

But, this code was altered in a follow up merge - maybe the merge was problematic?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334437424

From mcimadamore at openjdk.org  Fri Sep 22 14:34:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 14:34:23 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
Message-ID: 

On Mon, 18 Sep 2023 14:17:30 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:
> 
>   Avoid eager use of LibFallback in FallbackLinker static block

Marked as reviewed by mcimadamore (Reviewer).

test/micro/org/openjdk/bench/java/lang/foreign/AllocFromSliceTest.java line 48:

> 46: @State(org.openjdk.jmh.annotations.Scope.Thread)
> 47: @OutputTimeUnit(TimeUnit.NANOSECONDS)
> 48: @Fork(value = 3, jvmArgsAppend = { "--enable-native-access=ALL-UNNAMED" })

native access not needed?

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstant.java line 51:

> 49: @State(org.openjdk.jmh.annotations.Scope.Thread)
> 50: @OutputTimeUnit(TimeUnit.MILLISECONDS)
> 51: @Fork(value = 3, jvmArgsAppend = { "--enable-native-access=ALL-UNNAMED" })

Is native access needed?

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverSlice.java line 52:

> 50: @State(org.openjdk.jmh.annotations.Scope.Thread)
> 51: @OutputTimeUnit(TimeUnit.MILLISECONDS)
> 52: @Fork(value = 3, jvmArgsAppend = { "--enable-native-access=ALL-UNNAMED" })

Is --enable-native-access needed?

test/micro/org/openjdk/bench/java/lang/foreign/TestLoadBytes.java line 52:

> 50: @OutputTimeUnit(TimeUnit.NANOSECONDS)
> 51: @Fork(value = 1, jvmArgsAppend = {
> 52:         "-Dforeign.restricted=permit",

This seems obsolete? Maybe check other files too

-------------

PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1640071167
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334460809
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334456849
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334455707
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334452394

From jvernee at openjdk.org  Fri Sep 22 14:34:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 14:34:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
 
 
Message-ID: 

On Fri, 22 Sep 2023 14:10:58 GMT, Maurizio Cimadamore  wrote:

>> Also, in the panama repo I see this:
>> 
>> Allocates a memory segment with the given layout and initializes it with the bytes in the provided source memory segment.
>> 
>> Which seems more correct - e.g. more consistent with other allocation methods, and also more succinct (note that the first sentence is really what shows up in the method summary javadoc, so there is a certain interest in providing a quick description of what the method does,
>
> Panama repo change:
> https://github.com/openjdk/panama-foreign/commit/06e2017883c939188103c4dd53185417a00b2921
> 
> But, this code was altered in a follow up merge - maybe the merge was problematic?

This was changed in the main line repo as a result of: https://github.com/openjdk/jdk/pull/14997 Since all the other methods were using `{@return ...}` I changed this new overload to that style as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334462650

From jvernee at openjdk.org  Fri Sep 22 14:34:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 14:34:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
 
 
 
Message-ID: 

On Fri, 22 Sep 2023 14:31:08 GMT, Jorn Vernee  wrote:

>> Panama repo change:
>> https://github.com/openjdk/panama-foreign/commit/06e2017883c939188103c4dd53185417a00b2921
>> 
>> But, this code was altered in a follow up merge - maybe the merge was problematic?
>
> This was changed in the main line repo as a result of: https://github.com/openjdk/jdk/pull/14997 Since all the other methods were using `{@return ...}` I changed this new overload to that style as well.

I think I did the same when resolving the merge

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334463091

From jvernee at openjdk.org  Fri Sep 22 14:38:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 14:38:22 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
 
 
 
 
Message-ID: <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>

On Fri, 22 Sep 2023 14:31:30 GMT, Jorn Vernee  wrote:

>> This was changed in the main line repo as a result of: https://github.com/openjdk/jdk/pull/14997 Since all the other methods were using `{@return ...}` I changed this new overload to that style as well.
>
> I think I did the same when resolving the merge

I don't mind changing it back to the old style, but I think the style should be consistent for all the allocateFrom overloads? So, I'd have to change all of them back.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334468243

From duke at openjdk.org  Fri Sep 22 14:47:18 2023
From: duke at openjdk.org (Glavo)
Date: Fri, 22 Sep 2023 14:47:18 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v3]
In-Reply-To: <8Y_HVJGTPU6vuu1YlwLrHJvAzNCTekesg6eSmGZu3QI=.5ff02864-ec82-4c2a-a21a-13d987852ff9@github.com>
References: 
 <8Y_HVJGTPU6vuu1YlwLrHJvAzNCTekesg6eSmGZu3QI=.5ff02864-ec82-4c2a-a21a-13d987852ff9@github.com>
Message-ID: 

On Thu, 21 Sep 2023 16:40:59 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 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

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();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1334479768

From jvernee at openjdk.org  Fri Sep 22 14:50:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 14:50:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
Message-ID: <9eYdE4uXg5zGj4yfFRFYNwpHFMbA_25yqPOhgq6n7vA=.0a40fc9c-86e3-4fef-96f4-d68a82c07438@github.com>

On Fri, 22 Sep 2023 14:29:35 GMT, Maurizio Cimadamore  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid eager use of LibFallback in FallbackLinker static block
>
> test/micro/org/openjdk/bench/java/lang/foreign/AllocFromSliceTest.java line 48:
> 
>> 46: @State(org.openjdk.jmh.annotations.Scope.Thread)
>> 47: @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> 48: @Fork(value = 3, jvmArgsAppend = { "--enable-native-access=ALL-UNNAMED" })
> 
> native access not needed?

This class extends `CLayouts` which also creates some native method handles, so it's needed here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334484155

From rriggs at openjdk.org  Fri Sep 22 14:51:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 22 Sep 2023 14:51:16 GMT
Subject: RFR: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind [v9]
In-Reply-To: 
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
 
Message-ID: 

On Thu, 21 Sep 2023 15:35:16 GMT, Brian Burkhalter  wrote:

>> Add a `finally` block to delete the created files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315960: Use assertEquals

Looking good.
It may be useful to update the PR description and Issue description to include the refactoring of the test to Junit.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15757#pullrequestreview-1640123475

From jlaskey at openjdk.org  Fri Sep 22 14:55:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 22 Sep 2023 14:55:14 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
 
 
Message-ID: 

On Fri, 22 Sep 2023 13:50:37 GMT, ???  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 jvernee at openjdk.org  Fri Sep 22 15:09:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 15:09:24 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 13:39:00 GMT, Maurizio Cimadamore  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid eager use of LibFallback in FallbackLinker static block
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 152:
> 
>> 150:  * 

>> 151:  * The following table shows some examples of how C types are modelled in Linux/x64 according to the
>> 152:  * "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (all the examples provided
> 
> I have seen some discussion on this and I agree an authoritative link does not exist (I have searched for it in the past). I guess I'm not super wild about also including "AMD64 Architecture Processor Supplement". E.g. IMHO "System V Application Binary Interface" is more than enough?

Ok, I think I agree, given that we already name x64 as a platform.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334509092

From jvernee at openjdk.org  Fri Sep 22 15:20:08 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 15:20:08 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
Message-ID: 

On Mon, 18 Sep 2023 14:17:30 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:
> 
>   Avoid eager use of LibFallback in FallbackLinker static block

After some offline discussion, the changes for adding the `Enable-Native-Access` jar manifest attribute have now bee added too:

- commit: https://github.com/openjdk/jdk/pull/15103/commits/6b24e886588a32845249e6d684c5219c27dbf751
- Original PR: https://github.com/openjdk/panama-foreign/pull/843

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1731594343

From jvernee at openjdk.org  Fri Sep 22 15:20:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 15:20:05 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v23]
In-Reply-To: 
References: 
Message-ID: <0DuiWnffjpUzBASIfbHchpCP-b75VBI4evA6bb9o_eo=.25faef35-e2ef-47c3-bf97-ffd3dd2a8fd9@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 with a new target base due to a merge or a rebase. The pull request now contains 49 commits:

 - remove unneeded benchmark flags
 - Merge branch 'master' into JEP22
 - 8310659: The jar tool should support allowing access to restricted methods from executable jars
   
   Reviewed-by: mcimadamore
 - Avoid eager use of LibFallback in FallbackLinker static block
 - add missing space + reflow lines
 - Fix typo
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - 8315917: Passing struct by values seems under specified
   
   Reviewed-by: mcimadamore
 - Merge branch 'master' into JEP22
 - Merge branch 'master' into JEP22
 - add code snippet
 - ... and 39 more: https://git.openjdk.org/jdk/compare/c90d6310...5b64181d

-------------

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=22
  Stats: 4255 lines in 253 files changed: 2191 ins; 1200 del; 864 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 mcimadamore at openjdk.org  Fri Sep 22 15:22:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 15:22:18 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
 
 
 
 
 <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
Message-ID: <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>

On Fri, 22 Sep 2023 14:35:12 GMT, Jorn Vernee  wrote:

>> I think I did the same when resolving the merge
>
> I don't mind changing it back to the old style, but I think the style should be consistent for all the allocateFrom overloads? So, I'd have to change all of them back.

I forgot about the change that went into mainline. Do you have a link of the latest javadoc? I'd like to check how the method summary looks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334524306

From rgiulietti at openjdk.org  Fri Sep 22 15:31:18 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 22 Sep 2023 15:31:18 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 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_r1334533360

From liach at openjdk.org  Fri Sep 22 15:33:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 15:33:26 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v23]
In-Reply-To: <0DuiWnffjpUzBASIfbHchpCP-b75VBI4evA6bb9o_eo=.25faef35-e2ef-47c3-bf97-ffd3dd2a8fd9@github.com>
References: 
 <0DuiWnffjpUzBASIfbHchpCP-b75VBI4evA6bb9o_eo=.25faef35-e2ef-47c3-bf97-ffd3dd2a8fd9@github.com>
Message-ID: 

On Fri, 22 Sep 2023 15:20:05 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 with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - remove unneeded benchmark flags
>  - Merge branch 'master' into JEP22
>  - 8310659: The jar tool should support allowing access to restricted methods from executable jars
>    
>    Reviewed-by: mcimadamore
>  - Avoid eager use of LibFallback in FallbackLinker static block
>  - add missing space + reflow lines
>  - Fix typo
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - 8315917: Passing struct by values seems under specified
>    
>    Reviewed-by: mcimadamore
>  - Merge branch 'master' into JEP22
>  - Merge branch 'master' into JEP22
>  - add code snippet
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/c90d6310...5b64181d

Just curious, for `Enable-Native-Access`, if it's present on an automatic module `Automatic-Module-Name` jar, can it apply to only that automatic module instead of all unnamed modules?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1731612017

From jvernee at openjdk.org  Fri Sep 22 15:33:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 15:33:27 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v23]
In-Reply-To: 
References: 
 <0DuiWnffjpUzBASIfbHchpCP-b75VBI4evA6bb9o_eo=.25faef35-e2ef-47c3-bf97-ffd3dd2a8fd9@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 15:26:45 GMT, Chen Liang  wrote:

> Just curious, for `Enable-Native-Access`, if it's present on an automatic module `Automatic-Module-Name` jar, can it apply to only that automatic module instead of all unnamed modules?

No. It's only there for executable jars (run using `java -jar`), which are always placed on the class path.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1731617936

From liach at openjdk.org  Fri Sep 22 15:34:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 15:34:19 GMT
Subject: RFR: 8316493: Make immutable maps @ValueBased [v3]
In-Reply-To: 
References: 
 <8Y_HVJGTPU6vuu1YlwLrHJvAzNCTekesg6eSmGZu3QI=.5ff02864-ec82-4c2a-a21a-13d987852ff9@github.com>
 
Message-ID: <3bDFFHdMJo1fITcmFynsbMoC9fsyJ8wpFp5_Ww1Zn7k=.e2113679-680b-401e-b625-ae47de4c711a@github.com>

On Fri, 22 Sep 2023 14:44:11 GMT, Glavo  wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - 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
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15614#discussion_r1334536969

From rgiulietti at openjdk.org  Fri Sep 22 15:36:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 22 Sep 2023 15:36:15 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 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 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`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334537273
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334539144

From rgiulietti at openjdk.org  Fri Sep 22 15:52:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 22 Sep 2023 15:52:17 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 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1334556250

From bpb at openjdk.org  Fri Sep 22 15:54:18 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 22 Sep 2023 15:54:18 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 31 Jul 2023 17:02:15 GMT, Brian Burkhalter  wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   6478546: do-while -> while-do in writeBytes; remove NULL and bounds checks in native

Still need to derive a valid value for the maximum read/write size by benchmarks which are not just measuring the file system cache.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14981#issuecomment-1731651137

From duke at openjdk.org  Fri Sep 22 16:02:49 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Fri, 22 Sep 2023 16:02:49 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti [v2]
In-Reply-To: 
References: 
Message-ID: <0is3X-UBRePUPKJhotvwSMGXcOfA2J73KRb3NJCEIgg=.0a3728d9-6e5f-403b-b2de-bb3b6e4e13ef@github.com>

> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Display links to Stream.flatMap and Stream.mapMulti without parameters.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15794/files
  - new: https://git.openjdk.org/jdk/pull/15794/files/4ff703e0..8e9f38ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15794&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15794&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15794/head:pull/15794

PR: https://git.openjdk.org/jdk/pull/15794

From liach at openjdk.org  Fri Sep 22 16:18:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 16:18:12 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti [v2]
In-Reply-To: <0is3X-UBRePUPKJhotvwSMGXcOfA2J73KRb3NJCEIgg=.0a3728d9-6e5f-403b-b2de-bb3b6e4e13ef@github.com>
References: 
 <0is3X-UBRePUPKJhotvwSMGXcOfA2J73KRb3NJCEIgg=.0a3728d9-6e5f-403b-b2de-bb3b6e4e13ef@github.com>
Message-ID: 

On Fri, 22 Sep 2023 16:02:49 GMT, Mourad Abbay  wrote:

>> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Display links to Stream.flatMap and Stream.mapMulti without parameters.

Marked as reviewed by liach (Author).

src/java.base/share/classes/java/util/stream/Stream.java line 423:

> 421:      *               function that generates replacement elements
> 422:      * @return the new stream
> 423:      * @see #flatMap

These and the lines below (461, 499, 537) should be restored

-------------

PR Review: https://git.openjdk.org/jdk/pull/15794#pullrequestreview-1640282564
PR Review Comment: https://git.openjdk.org/jdk/pull/15794#discussion_r1334586381

From jvernee at openjdk.org  Fri Sep 22 16:32:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 16:32:27 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
 
 
 
 
 <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
 <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>
Message-ID: 

On Fri, 22 Sep 2023 15:19:35 GMT, Maurizio Cimadamore  wrote:

>> I don't mind changing it back to the old style, but I think the style should be consistent for all the allocateFrom overloads? So, I'd have to change all of them back.
>
> I forgot about the change that went into mainline. Do you have a link of the latest javadoc? I'd like to check how the method summary looks.

Here you go: https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,long)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334600062

From darcy at openjdk.org  Fri Sep 22 16:39:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 22 Sep 2023 16:39:21 GMT
Subject: Integrated: JDK-8316688: Widen allowable error bound of Math.hypot
In-Reply-To: <7CBst1Ry34RNh_v--gOWkGXyl1bISdzDV9Rp1g4zqmQ=.bf9cf4e6-6c9d-457d-b8c1-54ce2df362fc@github.com>
References: <7CBst1Ry34RNh_v--gOWkGXyl1bISdzDV9Rp1g4zqmQ=.bf9cf4e6-6c9d-457d-b8c1-54ce2df362fc@github.com>
Message-ID: 

On Thu, 21 Sep 2023 19:19:34 GMT, Joe Darcy  wrote:

> The Math.hypot method claims its error bound is one ulp.
> 
> The paper
> 
> "Accuracy of Mathematical Functions in Single, Double, Double
> Extended, and Quadruple Precision"
> Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> September 21, 2023
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> lists a known worst-case error of 1.21 ulps for hypot for the "OpenLibm" math library, which is a derivative of FDLIBM.
> 
> The specification of Math.hypot should be updated to acknowledge the wider error bound. I changed the allowable error bound to 1.5 ulps is give a bit of cushion.

This pull request has now been integrated.

Changeset: b66ded9a
Author:    Joe Darcy 
URL:       https://git.openjdk.org/jdk/commit/b66ded9a5b699e4936db25b58944587432e64f46
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8316688: Widen allowable error bound of Math.hypot

Reviewed-by: bpb, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/15868

From jvernee at openjdk.org  Fri Sep 22 16:40:04 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 16:40:04 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v24]
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:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/5b64181d..1c24f33e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=22-23

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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 Sep 22 16:40:08 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 16:40:08 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 13:41:50 GMT, Maurizio Cimadamore  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid eager use of LibFallback in FallbackLinker static block
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 409:
> 
>> 407:  *
>> 408:  * Variadic functions are C functions which can accept a variable number and type of arguments. They are declared with a
>> 409:  * trailing ellipsis ({@code ...}) at the end of the formal parameter list, such as: {@code void foo(int x, ...);}.
> 
> Looking at the javadoc - it seems to me that the `;` after the declaration of `foo` leads to a bit of jarring as it is immediately followed by a period (`.`). Consider dropping that - or maybe put the declaration in a snippet.

Will drop the period

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334604329

From duke at openjdk.org  Fri Sep 22 16:53:21 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 22 Sep 2023 16:53:21 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: 

> 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 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/b04cb6c3..dbf43321

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=39-40

  Stats: 18 lines in 2 files changed: 0 ins; 2 del; 16 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 naoto at openjdk.org  Fri Sep 22 16:54:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Sep 2023 16:54:16 GMT
Subject: RFR: 8316540: StoreReproducibilityTest fails on some locales [v3]
In-Reply-To: 
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
 
Message-ID: 

On Thu, 21 Sep 2023 18:51:50 GMT, Naoto Sato  wrote:

>> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use createTestJvm for vm invocation

Thanks for all the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15829#issuecomment-1731737450

From naoto at openjdk.org  Fri Sep 22 16:57:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Sep 2023 16:57:22 GMT
Subject: Integrated: 8316540: StoreReproducibilityTest fails on some locales
In-Reply-To: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
References: <7lIuOEw0cbnX6E4E7dgaTKWFE-0Sae_UueQThZX4wBA=.060b07d3-8db7-4089-a4db-7fb254d4e47e@github.com>
Message-ID: <9eqGT8p09mq4A9OP6LSR1v4WhcW6hNmIroPZs7-C5rc=.7bc2006d-60cf-438c-8ac1-4c46dcc2a1c9@github.com>

On Tue, 19 Sep 2023 22:49:36 GMT, Naoto Sato  wrote:

> Fixing a test case that fails in some time zones. Making sure the test is run in `UTC` zone will fix the issue. Confirmed the fix by manually setting machine's time zone to Europe/Dublin.

This pull request has now been integrated.

Changeset: f7578e80
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/f7578e8048ee961f22b57ee2b7eed9e9ab783cf5
Stats:     18 lines in 1 file changed: 4 ins; 0 del; 14 mod

8316540: StoreReproducibilityTest fails on some locales

Reviewed-by: joehw, jlu, jpai, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15829

From mcimadamore at openjdk.org  Fri Sep 22 17:01:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 17:01:22 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: 
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
 
 
 
 
 <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
 <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>
 
Message-ID: <17Hdk-QZiKVqpNzEV_v3vhd6uqDTdIdNpIYQmbETPNc=.ee3d0448-684d-4e67-abcf-f2af95bd1ea5@github.com>

On Fri, 22 Sep 2023 16:29:51 GMT, Jorn Vernee  wrote:

>> I forgot about the change that went into mainline. Do you have a link of the latest javadoc? I'd like to check how the method summary looks.
>
> Here you go: https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,long)

Ok, now I'm more convinced that the method summary really does look bad (or worse, compared to 20).

For instance [allocateFrom](https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout.OfByte,byte...):


Returns a new memory segment with a byteSize() initialized with the provided E byte elements as specified by the provided layout (i.e. byte ordering, alignment and size).


(same is true for all the other array-accepting `allocateFrom` methods). This should be simplified to:


Returns a new memory segment initialized with the elements in the provided byte array.

(then, if we want to say that the initialization honors the endianness of the provided layout, we can do so in a followup para, but the method summary should be simple).

So, once all the array-accepting methods are fixed, the segment-accepting `allocateFrom` needs to be simplified to:


Returns a new memory segment initialized with the contents of the provided segment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334627056

From duke at openjdk.org  Fri Sep 22 17:08:48 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Fri, 22 Sep 2023 17:08:48 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti [v3]
In-Reply-To: 
References: 
Message-ID: 

> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Display links to Stream.flatMap and Stream.mapMulti without parameters.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15794/files
  - new: https://git.openjdk.org/jdk/pull/15794/files/8e9f38ac..7e3b5b59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15794&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15794&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15794/head:pull/15794

PR: https://git.openjdk.org/jdk/pull/15794

From bpb at openjdk.org  Fri Sep 22 17:27:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 22 Sep 2023 17:27:24 GMT
Subject: Integrated: 8315960: test/jdk/java/io/File/TempDirDoesNotExist.java
 leaves test files behind
In-Reply-To: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
References: <6xsK-yOzdnvrRe5Nna9slSsA1ohbHavD5WrkJce_6E8=.bf4f2044-6eb9-4899-b6a1-e810c5e6fb80@github.com>
Message-ID: 

On Thu, 14 Sep 2023 21:53:30 GMT, Brian Burkhalter  wrote:

> Add a `finally` block to delete the created files. Convert the test to JUnit 5.

This pull request has now been integrated.

Changeset: 373cdf25
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/373cdf257de78940b2e55e9f5fc38b6233561baf
Stats:     114 lines in 1 file changed: 55 ins; 20 del; 39 mod

8315960: test/jdk/java/io/File/TempDirDoesNotExist.java leaves test files behind

Reviewed-by: lancea, djelinski, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/15757

From mchung at openjdk.org  Fri Sep 22 17:32:32 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 22 Sep 2023 17:32:32 GMT
Subject: RFR: 8316305: Initial buffer size of StackWalker is too small
 caused by JDK-8285447 [v4]
In-Reply-To: 
References: 
Message-ID: <65456kyEsTtdCiaGqV7BoDSgEfdytQibmTBOx-ZO6MI=.b9f55afe-6df1-4e1f-ad74-a5ec737eed11@github.com>

> A trivial fix.   [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) intends to change the initial batch size only for a stack walker with an estimated stack depth. For stack walkers without user-supplied estimated stack depth, the initial batch size is changed to 3 which is a bug.  This causes the stack walker to fetch the second batch after walking 2 frames.

Mandy Chung 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' of https://github.com/openjdk/jdk into JDK-8316305
 - Revert this change. PR 15876
 - Fix a warning caused by 8316456
 - Merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8316305
 - 8316305: Initial buffer size of StackWalker is too small caused by JDK-8285447

-------------

Changes: https://git.openjdk.org/jdk/pull/15749/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15749&range=03
  Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15749/head:pull/15749

PR: https://git.openjdk.org/jdk/pull/15749

From rgiulietti at openjdk.org  Fri Sep 22 17:39:53 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 22 Sep 2023 17:39:53 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v2]
In-Reply-To: 
References: 
Message-ID: 

> 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 incrementally with one additional commit since the last revision:

  Uppercase JLA.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15861/files
  - new: https://git.openjdk.org/jdk/pull/15861/files/97f0c7b4..092c2046

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15861&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15861&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 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 Sep 22 17:55:15 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 22 Sep 2023 17:55:15 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Fri, 22 Sep 2023 09:22:04 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore HexDigits & OctalDigits

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

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1731821226

From psandoz at openjdk.org  Fri Sep 22 18:13:12 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 22 Sep 2023 18:13:12 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 17:08:48 GMT, Mourad Abbay  wrote:

>> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Display links to Stream.flatMap and Stream.mapMulti without parameters.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15794#pullrequestreview-1640438479

From bchristi at openjdk.org  Fri Sep 22 18:33:13 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 22 Sep 2023 18:33:13 GMT
Subject: RFR: 8316305: Initial buffer size of StackWalker is too small
 caused by JDK-8285447 [v4]
In-Reply-To: <65456kyEsTtdCiaGqV7BoDSgEfdytQibmTBOx-ZO6MI=.b9f55afe-6df1-4e1f-ad74-a5ec737eed11@github.com>
References: 
 <65456kyEsTtdCiaGqV7BoDSgEfdytQibmTBOx-ZO6MI=.b9f55afe-6df1-4e1f-ad74-a5ec737eed11@github.com>
Message-ID: <7XPnd3DY6or4OgyI-PzdPxADYVtlBMVYSUsgX5sIq70=.a843c146-8a2b-4485-a431-028ae1b6411e@github.com>

On Fri, 22 Sep 2023 17:32:32 GMT, Mandy Chung  wrote:

>> A trivial fix.   [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) intends to change the initial batch size only for a stack walker with an estimated stack depth. For stack walkers without user-supplied estimated stack depth, the initial batch size is changed to 3 which is a bug.  This causes the stack walker to fetch the second batch after walking 2 frames.
>
> Mandy Chung 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' of https://github.com/openjdk/jdk into JDK-8316305
>  - Revert this change. PR 15876
>  - Fix a warning caused by 8316456
>  - Merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8316305
>  - 8316305: Initial buffer size of StackWalker is too small caused by JDK-8285447

Marked as reviewed by bchristi (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15749#pullrequestreview-1640462720

From mchung at openjdk.org  Fri Sep 22 18:41:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 22 Sep 2023 18:41:22 GMT
Subject: Integrated: 8316305: Initial buffer size of StackWalker is too small
 caused by JDK-8285447
In-Reply-To: 
References: 
Message-ID: 

On Thu, 14 Sep 2023 17:06:53 GMT, Mandy Chung  wrote:

> A trivial fix.   [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447) intends to change the initial batch size only for a stack walker with an estimated stack depth. For stack walkers without user-supplied estimated stack depth, the initial batch size is changed to 3 which is a bug.  This causes the stack walker to fetch the second batch after walking 2 frames.

This pull request has now been integrated.

Changeset: 9b65b7dd
Author:    Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/9b65b7ddbe0696813c722dbfd2d97db3b301a7c1
Stats:     8 lines in 1 file changed: 1 ins; 2 del; 5 mod

8316305: Initial buffer size of StackWalker is too small caused by JDK-8285447

Reviewed-by: bchristi

-------------

PR: https://git.openjdk.org/jdk/pull/15749

From jlu at openjdk.org  Fri Sep 22 19:50:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Sep 2023 19:50:49 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
> 
> Any files named BugXXXXXXX.java will be renamed after review.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Review: revert removal of SupressWarnings annotation
 - Reflect review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15853/files
  - new: https://git.openjdk.org/jdk/pull/15853/files/43e17eb8..a0cfa852

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=00-01

  Stats: 51 lines in 7 files changed: 35 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/15853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15853/head:pull/15853

PR: https://git.openjdk.org/jdk/pull/15853

From jlu at openjdk.org  Fri Sep 22 19:50:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Sep 2023 19:50:50 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v2]
In-Reply-To: <_8mFOdsLmNXEdsF_B3MooAsKrZUo2TsiBjkxWAfXEmY=.6081fd06-277e-4485-9de1-6b68fe94b80b@github.com>
References: 
 <_8mFOdsLmNXEdsF_B3MooAsKrZUo2TsiBjkxWAfXEmY=.6081fd06-277e-4485-9de1-6b68fe94b80b@github.com>
Message-ID: 

On Fri, 22 Sep 2023 06:44:16 GMT, Andrey Turbanov  wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Review: revert removal of SupressWarnings annotation
>>  - Reflect review comments
>
> test/jdk/java/util/Calendar/BuddhistCalendarTest.java line 141:
> 
>> 139:     @Test
>> 140:     public void buddhistSetTest() {
>> 141:         Calendar cal  = getBuddhistCalendar();
> 
> Suggestion:
> 
>         Calendar cal = getBuddhistCalendar();

Fixed, thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1334759775

From jlu at openjdk.org  Fri Sep 22 19:50:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Sep 2023 19:50:50 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v2]
In-Reply-To: 
References: 
 
Message-ID: <1uvRsz9j5CwOBZb_uiOzYGpLJ_gvP6Yz2v4WRzZZTkc=.e8128cbc-dd88-42ee-bed9-8cbdb617bcd0@github.com>

On Thu, 21 Sep 2023 22:18:04 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Review: revert removal of SupressWarnings annotation
>>  - Reflect review comments
>
> test/jdk/java/util/Calendar/Bug4766302.java line 32:
> 
>> 30: import java.util.GregorianCalendar;
>> 31: 
>> 32: @SuppressWarnings("serial")
> 
> Is removing this OK?

At first I thought so, there is no warning about a missing serialVersionUID when the _SuppressWarnings_ annotation is removed, and IntelliJ actually flags the annotation as redundant. But since it was added separately and intentionally in [JDK-8165296](https://bugs.openjdk.org/browse/JDK-8165296), I would rather leave it alone on second thought.

> test/jdk/java/util/Calendar/bug4243802.java line 48:
> 
>> 46:     void setUp() {
>> 47:         Locale.setDefault(Locale.US);
>> 48:         TimeZone.setDefault(TimeZone.getTimeZone("America/Los_Angeles"));
> 
> If the test is not going to restore the original defaults with `tearDown()`, I'd expect `othervm` explicitly on `@run` directive. (applies to other locations)

Thanks for correcting that, I had a misconception that JUnit would be ran with an independent JVM (not potentially reused), which is why I removed the saving of the default TZ and Locale. Adjusted so that they are preserved and reset with a tearDown() method.

> test/jdk/java/util/Calendar/bug4316678.java line 58:
> 
>> 56:     @Test
>> 57:     public void serializationTest() throws IOException, ClassNotFoundException {
>> 58:         TimeZone.setDefault(TimeZone.getTimeZone("PST"));
> 
> Not needed?

Missed that, thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1334759820
PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1334759634
PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1334759740

From naoto at openjdk.org  Fri Sep 22 20:27:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Sep 2023 20:27:13 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v2]
In-Reply-To: <1uvRsz9j5CwOBZb_uiOzYGpLJ_gvP6Yz2v4WRzZZTkc=.e8128cbc-dd88-42ee-bed9-8cbdb617bcd0@github.com>
References: 
 
 <1uvRsz9j5CwOBZb_uiOzYGpLJ_gvP6Yz2v4WRzZZTkc=.e8128cbc-dd88-42ee-bed9-8cbdb617bcd0@github.com>
Message-ID: 

On Fri, 22 Sep 2023 19:44:00 GMT, Justin Lu  wrote:

>> test/jdk/java/util/Calendar/Bug4766302.java line 32:
>> 
>>> 30: import java.util.GregorianCalendar;
>>> 31: 
>>> 32: @SuppressWarnings("serial")
>> 
>> Is removing this OK?
>
> At first I thought so, there is no warning about a missing serialVersionUID when the _SuppressWarnings_ annotation is removed, and IntelliJ actually flags the annotation as redundant. But since it was added separately and intentionally in [JDK-8165296](https://bugs.openjdk.org/browse/JDK-8165296), I would rather leave it alone on second thought.

Not sure why IntelliJ claims it redundant, but compiling the test case alone, without that `@SuppressWarnings` with `-Xlint` gives me this:

warning: [serial] serializable class MyCalendar has no definition of serialVersionUID

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15853#discussion_r1334788356

From naoto at openjdk.org  Fri Sep 22 20:32:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 22 Sep 2023 20:32:13 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 19:50:49 GMT, Justin Lu  wrote:

>> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
>> 
>> Any files named BugXXXXXXX.java will be renamed after review.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review: revert removal of SupressWarnings annotation
>  - Reflect review comments

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15853#pullrequestreview-1640604118

From lancea at openjdk.org  Fri Sep 22 20:48:12 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 22 Sep 2023 20:48:12 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 19:50:49 GMT, Justin Lu  wrote:

>> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
>> 
>> Any files named BugXXXXXXX.java will be renamed after review.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review: revert removal of SupressWarnings annotation
>  - Reflect review comments

Overall, this is fine.

I would like to suggest comments to introduce all tests and DataProviders.  Extra credit for helper methods.

>From a future maintainers Point of view, having more info in the tests is beneficial.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15853#pullrequestreview-1640620487

From darcy at openjdk.org  Fri Sep 22 20:54:19 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 22 Sep 2023 20:54:19 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v2]
In-Reply-To: 
References: 
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.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add stated error bounds.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15879/files
  - new: https://git.openjdk.org/jdk/pull/15879/files/57b112cd..3b5fc48c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=00-01

  Stats: 27 lines in 1 file changed: 27 ins; 0 del; 0 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  Fri Sep 22 21:39:08 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 22 Sep 2023 21:39:08 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v3]
In-Reply-To: 
References: 
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.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo found in code review.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15879/files
  - new: https://git.openjdk.org/jdk/pull/15879/files/3b5fc48c..2442b72f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=01-02

  Stats: 1 line in 1 file changed: 0 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  Fri Sep 22 21:39:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 22 Sep 2023 21:39:09 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 15:27:51 GMT, Raffaello Giulietti  wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo found in code review.
>
> 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 jlu at openjdk.org  Fri Sep 22 22:11:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Sep 2023 22:11:59 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
> 
> Any files named BugXXXXXXX.java will be renamed after review.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Add more comments, drop @library tag for tests previously extending IntlTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15853/files
  - new: https://git.openjdk.org/jdk/pull/15853/files/a0cfa852..99fd7b24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=01-02

  Stats: 101 lines in 9 files changed: 69 ins; 4 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/15853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15853/head:pull/15853

PR: https://git.openjdk.org/jdk/pull/15853

From jlu at openjdk.org  Fri Sep 22 22:12:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Sep 2023 22:12:00 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 22 Sep 2023 20:45:39 GMT, Lance Andersen  wrote:

> Overall, this is fine.
> 
> I would like to suggest comments to introduce all tests and DataProviders. Extra credit for helper methods.
> 
> From a future maintainers Point of view, having more info in the tests is beneficial.

Thanks for reviewing Lance. Agreed, there's been times where I've wished there was more context in the test file itself, rather than having to navigate to the JBS issue or older diffs for more info. 

Updated to have comments for tests, data providers, and helper methods as you suggested (will do the same for future JUnit conversions).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15853#issuecomment-1732078935

From jlu at openjdk.org  Fri Sep 22 22:32:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Sep 2023 22:32:00 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
> 
> Any files named BugXXXXXXX.java will be renamed after review.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  white space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15853/files
  - new: https://git.openjdk.org/jdk/pull/15853/files/99fd7b24..db54d231

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15853/head:pull/15853

PR: https://git.openjdk.org/jdk/pull/15853

From duke at openjdk.org  Fri Sep 22 22:32:52 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Fri, 22 Sep 2023 22:32:52 GMT
Subject: RFR: 8271268: Fix Javadoc links for Stream.mapMulti [v4]
In-Reply-To: 
References: 
Message-ID: <8rwM1aaTi6O7HxKRzVf_-Hj4St8D1mbzxdWQvbW5RaU=.80a18214-65dc-4958-a3e9-2767362257b1@github.com>

> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.

Mourad Abbay 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/15794/files
  - new: https://git.openjdk.org/jdk/pull/15794/files/7e3b5b59..b4543738

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15794&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15794&range=02-03

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15794/head:pull/15794

PR: https://git.openjdk.org/jdk/pull/15794

From bpb at openjdk.org  Fri Sep 22 22:46:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 22 Sep 2023 22:46:43 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v5]
In-Reply-To: 
References: 
Message-ID: 

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316000: Align the spec and return verbiage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15673/files
  - new: https://git.openjdk.org/jdk/pull/15673/files/8640decd..8189784a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=03-04

  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/15673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15673/head:pull/15673

PR: https://git.openjdk.org/jdk/pull/15673

From bpb at openjdk.org  Fri Sep 22 22:46:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 22 Sep 2023 22:46:43 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v4]
In-Reply-To: 
References: 
 
 
Message-ID: <-te3JKNnS-2Ldp75eDU7PxUD0sdl7MLr74U7un9GL70=.61ea8501-c124-42a7-89fb-7ec74b960d19@github.com>

On Thu, 21 Sep 2023 08:32:21 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316000: Move apiNotes to normative text; update @return descriptions
>
> src/java.base/share/classes/java/io/File.java line 1643:
> 
>> 1641:      *          change the access permissions of this abstract pathname.  If
>> 1642:      *          the underlying file system does not implement a read permission,
>> 1643:      *          then the operation will return the value of the {@code readable}
> 
> There's a switcharoo here. The method description speaks of the platform not supporting file permissions. The return description changes terminology and speaks of the file system not implementating permissions. I think we'll get these consistent but overall the intent is okay.

Reconciled these in 8189784ace0a693a042f86505466806377684f80.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15673#discussion_r1334866057

From bchristi at openjdk.org  Sat Sep 23 02:39:17 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Sat, 23 Sep 2023 02:39:17 GMT
Subject: RFR: 8314896: additional clarifications to reversed() default
 methods' implementation requirements
In-Reply-To: 
References: 
Message-ID: <9NreW5HqI4mSdjPVqXbBddrRbpQkawpe7trKJaSYfYM=.5269748a-6348-4ce5-8e09-d5a2dd7e1056@github.com>

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.

Looks good.

-------------

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15799#pullrequestreview-1640769251

From duke at openjdk.org  Sat Sep 23 07:39:59 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 07:39:59 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v8]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  refactor HexDigits & OctalDigits & FormatItem, FormatItem#prepend provides two implementations: prependLatin1 and prependUTF16

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/97c7f025..f1cb9fd7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=06-07

  Stats: 293 lines in 7 files changed: 163 ins; 82 del; 48 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 liach at openjdk.org  Sat Sep 23 09:40:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 23 Sep 2023 09:40:11 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v8]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Sat, 23 Sep 2023 07:39:59 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor HexDigits & OctalDigits & FormatItem, FormatItem#prepend provides two implementations: prependLatin1 and prependUTF16

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1732267099

From duke at openjdk.org  Sat Sep 23 09:47:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 09:47:42 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v9]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  refactor HexDigits & OctalDigits & FormatItem, FormatItem#prepend provides two implementations: prependLatin1 and prependUTF16 [v2]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/f1cb9fd7..074c48ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=07-08

  Stats: 97 lines in 5 files changed: 73 ins; 14 del; 10 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 duke at openjdk.org  Sat Sep 23 10:03:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 10:03:11 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v9]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Sat, 23 Sep 2023 09:47:42 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor HexDigits & OctalDigits & FormatItem, FormatItem#prepend provides two implementations: prependLatin1 and prependUTF16 [v2]

> 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15699#issuecomment-1732271564

From liach at openjdk.org  Sat Sep 23 11:41:46 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 23 Sep 2023 11:41:46 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v4]
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 five commits:

 - Merge branch 'pr/15103' of https://github.com/openjdk/jdk into cleanup/vh-template-share
 - Post-merge cleanup
 - Merge branch 'pr/15103' of https://github.com/openjdk/jdk into cleanup/vh-template-share
 - byte array var handles can share a common base class
 - Clean up VarHandle template classes

-------------

Changes: https://git.openjdk.org/jdk/pull/15854/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=03
  Stats: 203 lines in 7 files changed: 58 ins; 79 del; 66 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 duke at openjdk.org  Sat Sep 23 11:55:48 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 11:55:48 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v10]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  refactor FormatItem, remove MethodHandle for maintainable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/074c48ef..4fda2f1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=08-09

  Stats: 154 lines in 4 files changed: 46 ins; 86 del; 22 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 duke at openjdk.org  Sat Sep 23 12:12:39 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 12:12:39 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v11]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  move String.getChars to DecimalDigits, and refactor FormatItem

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/4fda2f1e..44867687

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=09-10

  Stats: 247 lines in 5 files changed: 114 ins; 110 del; 23 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 duke at openjdk.org  Sat Sep 23 12:18:14 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 12:18:14 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v12]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  add CopyRight

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/44867687..fd589a8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=10-11

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 duke at openjdk.org  Sat Sep 23 12:37:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 12:37:10 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v7]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@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  Sat Sep 23 13:11:48 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 13:11:48 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v13]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  fix compile error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/fd589a8f..a613e5e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=11-12

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 erdong.me at gmail.com  Sat Sep 23 15:00:00 2023
From: erdong.me at gmail.com (Erdong Ren)
Date: Sat, 23 Sep 2023 23:00:00 +0800
Subject: A Discussion on Wrapper Class Source Code
In-Reply-To: 
References: 
Message-ID: 

Hi everyone,


In java.lang.Integer, there is the following code snippet:

static final int low = -128; // 936
int size = (high - low) + 1; // 961
int j = low; // 966

When I read the java.lang.Byte source code, I noticed that there is similar
logic, but the coding style is somewhat different. So I'm considering
whether I could modify the Byte source code to make their styles consistent:

@@ -107,6 +107,8 @@ public Optional>
describeConstable() {
     }

     private static final class ByteCache {
+        static final byte low = -128;
+
         private ByteCache() {}

         @Stable
@@ -114,13 +116,13 @@ private ByteCache() {}
         static Byte[] archivedCache;

         static {
-            final int size = -(-128) + 127 + 1;
+            int size = 127 - low + 1;

             // Load and use the archived cache if it exists
             CDS.initializeFromArchive(ByteCache.class);
             if (archivedCache == null || archivedCache.length != size) {
                 Byte[] c = new Byte[size];
-                byte value = (byte)-128;
+                byte value = low;
                 for(int i = 0; i < size; i++) {
                     c[i] = new Byte(value++);
                 }

The same goes for java.lang.Short, java.lang.Long.

Certainly, due to limited expertise, my ideas may not be reasonable. If
that's the case, I sincerely request corrections, thank you!

Looking forward to receiving messages from the community.

On Wed, Aug 9, 2023 at 9:00?AM Erdong Ren  wrote:

> Hello everyone,
>
> My name is Ren Erdong, and I am a Java developer from China. It's a
> pleasure to meet all of you, and I'm excited to join this community.
>
> While reading the source code of the wrapper classes, I have identified
> some areas that could potentially be optimized. However, I acknowledge that
> my considerations may not be comprehensive. Therefore, I would like to
> initiate a discussion with all of you to gather different perspectives and
> collectively explore possible optimizations.
>
> Actually, prior to this, I sent an email to the community, but it was
> held, stating that the message body was too large.
>
> *If this type of email shouldn't have been sent to this community, then I
> sincerely apologize. Please forgive me as a newcomer. I would appreciate
> your guidance on how to handle this matter correctly. Thank you very much!*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sat Sep 23 16:03:38 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 16:03:38 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v14]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: <7B1uvH1V9Sxir3yU_bUCnOKW-UkeZicuqcKYhlMQfUs=.b0244a86-816d-4966-a31b-230794af3e1a@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

??? has updated the pull request incrementally with one additional commit since the last revision:

  fix compile error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/a613e5e9..3ace6b78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=12-13

  Stats: 13 lines in 2 files changed: 4 ins; 7 del; 2 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 duke at openjdk.org  Sat Sep 23 17:44:51 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 17:44:51 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v15]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with two additional commits since the last revision:

 - bug fix for DecimalDigits#getCharsUTF16(int, int, byte[])
 - remove unused code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/3ace6b78..1ab0fbd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=13-14

  Stats: 8 lines in 2 files changed: 0 ins; 7 del; 1 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 duke at openjdk.org  Sat Sep 23 17:50:23 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 23 Sep 2023 17:50:23 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v15]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Sat, 23 Sep 2023 17:44:51 GMT, ???  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
>
> ??? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - bug fix for DecimalDigits#getCharsUTF16(int, int, byte[])
>  - remove unused code

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 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_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 duke at openjdk.org  Sat Sep 23 18:16:50 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 18:16:50 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v16]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: <78iQPTJP00aPYImoi4NIzRNVR_IRDaQOrHZH92dzCI4=.6695c30f-b30f-417b-af03-0751592bae49@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

??? has updated the pull request incrementally with two additional commits since the last revision:

 - remove unused throws
 - refactor from #15836

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/1ab0fbd0..e1c4fdea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=14-15

  Stats: 67 lines in 4 files changed: 20 ins; 16 del; 31 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 duke at openjdk.org  Sat Sep 23 18:22:39 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 18:22:39 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v17]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  remove unused throws

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/e1c4fdea..a7c21d24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=15-16

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 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 duke at openjdk.org  Sat Sep 23 19:19:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 19:19:42 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v18]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  refactor & bug fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/a7c21d24..ab6377ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=16-17

  Stats: 25 lines in 3 files changed: 4 ins; 12 del; 9 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 duke at openjdk.org  Sat Sep 23 19:55:48 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 19:55:48 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v19]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  fix build error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/ab6377ea..7f309780

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=17-18

  Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 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 duke at openjdk.org  Sat Sep 23 21:54:16 2023
From: duke at openjdk.org (iaroslavski)
Date: Sat, 23 Sep 2023 21:54:16 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>
 
 
 
Message-ID: 

On Thu, 21 Sep 2023 23:40:25 GMT, Srinivas Vamsi Parasa  wrote:

>>> Hi Vladimir,
>>> 
>>> Just trying to understand: is there a reason to use `DualPivotQuicksort_RadixForParallel.java` and `DualPivotQuicksort_RadixForAll.java`?
>>> 
>>> Would it not be sufficient to do the following two runs:
>>> 
>>> 1. Baseline (Stock JDK) vs. AVX512 sort for`sort()`and `parallelSort()` ?
>>> 2. AVX512 sort vs. Radix sort for `sort()` and `parallelSort()` ?
>>> 
>>> Thanks, Vamsi
>> 
>> Hi Vamsi (@vamsi-parasa)!
>> 
>> I appreciate if you kindly agree to help with perf runs on your environment.
>> Results from your runs will help us to detect the impact of Radix sort in *vectorized* sorting, this is very important topic.
>> 
>> Interesting comparisons are:
>> 
>> 1. AVX512 sort (your implementation) vs. DualPivotQuicksort_RadixForParallel (contains AVX512 + radix for parallel sort)
>>     https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForParallel.java
>> 
>> 2. AVX512 sort (your implementation) vs. DualPivotQuicksort_RadixForAll (contains AVX512 + radix for all)
>>     https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForAll.java
>> 
>> If you add the 3-rd comparison
>> baseline (stock JDK) vs. AVX512 sort - it would be great also!
>> 
>> Please use this JMH test to run on:
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java
>> 
>> * all sizes
>> * all inputs
>> * int type only
>> * sort() and parallelSort()
>> 
>> Looking forward the results,
>> Vladimir
>
> Hi Vladimir (@iaroslavski),
> 
> Kindly give me some time to do the JMH performance runs as I am currently occupied with various tasks related to the closing of the AVX512 sort PR.
> 
> Thanks,
> Vamsi

Sure, Vamsi @vamsi-parasa

Please find all my sorting classes
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForParallel.java
https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForAll.java

and benchmarking test
https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java

It is already prepared and contains all sizes, all inputs, sort() and parallelSort(), but int type only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1732416840

From duke at openjdk.org  Sat Sep 23 22:05:42 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 23 Sep 2023 22:05:42 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v20]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: <40Ju24d0ei8xWrqxUNuXB7xq2MWGbLVRn9FPO93dmDI=.912371d9-7e3e-4add-948e-520bd2cbce3f@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

??? has updated the pull request incrementally with one additional commit since the last revision:

  bug fix FormatItemDecimal::prepend

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/7f309780..ebbb5597

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=18-19

  Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 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 liach at openjdk.org  Sun Sep 24 02:11:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 24 Sep 2023 02:11:50 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v5]
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 incrementally with one additional commit since the last revision:

  Simplify non-Object array VH

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15854/files
  - new: https://git.openjdk.org/jdk/pull/15854/files/83f792e2..18d1be8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=03-04

  Stats: 122 lines in 2 files changed: 41 ins; 37 del; 44 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 duke at openjdk.org  Sun Sep 24 02:46:38 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 02:46:38 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v21]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  restore StringUTF16.getChars(int,int,int,byte[]) and StringUTF16.getChars(long,int,int,byte[])

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/ebbb5597..8ec66cca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=19-20

  Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 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 duke at openjdk.org  Sun Sep 24 06:07:55 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 06:07:55 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v2]
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:

  restore StringFormat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/59c2983b..20427517

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: 30 lines in 1 file changed: 0 ins; 30 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  Sun Sep 24 06:29:06 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 06:29:06 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v3]
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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_for_string_format
 - add decimal benchmark
 - restore StringFormat
 - shared between Formatter and FormatProcessor
 - refactor & bug fix
 - refactor
 - bug fix for '%T' not throw error
 - bug fix
 - drop the regex code entirely and write a custom parser
 - fix specifiers duplicate flags not throw error
 - ... and 9 more: https://git.openjdk.org/jdk/compare/a4bc76ae...2153a22e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/20427517..2153a22e

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: 27749 lines in 460 files changed: 14927 ins; 10416 del; 2406 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  Sun Sep 24 06:32:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 06:32:09 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v4]
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: <9TPLNP2znvus3NpNi19mWN57py_WZzLh57KWh1SojhA=.8d00f054-de9a-46e0-9d0e-8eca82b45167@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)

??? has updated the pull request incrementally with one additional commit since the last revision:

  import BigDecimal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/2153a22e..9f229b09

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: 1 line in 1 file changed: 1 ins; 0 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  Sun Sep 24 08:23:16 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 08:23:16 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: <1Sa-6-z846mIOS7Jw5pWTia7NhEjzjX-xOqWQCNI6g0=.5738194e-0996-49b5-8009-9a2e6e551c6c@github.com>
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
 <1Sa-6-z846mIOS7Jw5pWTia7NhEjzjX-xOqWQCNI6g0=.5738194e-0996-49b5-8009-9a2e6e551c6c@github.com>
Message-ID: 

On Tue, 19 Sep 2023 16:27:50 GMT, Roger Riggs  wrote:

> Lots of adhoc changes bulk up the source and make it less maintainable. Given the common element of time and date formatting strings as a domain specific language, there would be more benefit to leveraging one of several existing mechanisms to generate optimized formatters from application or library format strings. For example, the general purpose [JEP 430: String Template](https://openjdk.org/jeps/430)s could be used to compose the string and leverage its optimizations of formatting the components. Making improvements there either to performance or functionality would benefit more applications.
> 
> This also applies to [PR#15722](https://github.com/openjdk/jdk/pull/15722).

I submitted PR #15776 (Regex-free parsing of Formatter and FormatProcessor specifiers) to optimize the parse performance of String.format and StringFormatter. I submitted another PR #15699, the refactored code is related to String Template. 
After these two PRs are completed, I will continue to optimize java.util.Formatter.print and improve the performance of String.format and StringTemplate.

However, String.format and StringTemplate are different scenarios from this PR and PR#15722. Date/LocalDateTime/Instant#toString and DateTimeFormatter#format are very widely used, more widely used than String.format(Date/LocalDateTme/Instant). These Usage scenarios usually don't use String.format and StringTemplate instead.

The performance of using String.format and StringTemplate is not as good as using formatter and toString directly.

If you feel that the maintainability of these codes is not good enough, for example, we should reduce the use of ByteArrayLittleEndian, I can continue to improve these.

Because Date/LocalDateTime/Instant#toString and DateTimeFormatter#format are so widely used, I have also seen these methods taking a lot of time in flame graphs in business systems. I submitted this PR based on my business system optimization experience, so The optimization will directly improve the performance of the business system in certain scenarios.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1732518234

From duke at openjdk.org  Sun Sep 24 11:59:51 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 11:59:51 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v5]
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:

  refactor and cache single conversion FormatSpecifier

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/9f229b09..0d977b2f

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: 109 lines in 1 file changed: 64 ins; 10 del; 35 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 redestad at openjdk.org  Sun Sep 24 12:48:11 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 24 Sep 2023 12:48:11 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v5]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Sun, 24 Sep 2023 11:59:51 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:
> 
>   refactor and cache single conversion FormatSpecifier

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1732562759

From liach at openjdk.org  Sun Sep 24 13:06:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 24 Sep 2023 13:06:20 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: 

On Wed, 13 Sep 2023 14:22:35 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify LocalDate::getChars

For DateTimeFormatter, it first isn't effectively constant since its composite printerparser isn't immutable/stable. Also we can probably try if we can pre-allocate like for string concat to see if eliminated allocations help. For StringBuilder allocation, if JIT cannot eliminate it, we can probably switch to writing byte array + index since the interface in Formatter seems to be internal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1732565954

From duke at openjdk.org  Sun Sep 24 13:08:58 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 13:08:58 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v6]
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:

  Revert "refactor and cache single conversion FormatSpecifier"
  
  This reverts commit 0d977b2febe455f4535e6ee2cb19d3b168d764e3.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/0d977b2f..7b831ab6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=04-05

  Stats: 115 lines in 1 file changed: 16 ins; 70 del; 29 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  Sun Sep 24 13:11:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 13:11:11 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v5]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Sun, 24 Sep 2023 11:59:51 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:
> 
>   refactor and cache single conversion FormatSpecifier

> 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1732567054

From liach at openjdk.org  Sun Sep 24 13:16:02 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 24 Sep 2023 13:16:02 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v6]
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 incrementally with one additional commit since the last revision:

  Revert "Simplify non-Object array VH"
  
  This reverts commit 18d1be8b3b3aae1395d4096f5e2b95dbf078db0c.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15854/files
  - new: https://git.openjdk.org/jdk/pull/15854/files/18d1be8b..72836c28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=04-05

  Stats: 122 lines in 2 files changed: 37 ins; 41 del; 44 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 liach at openjdk.org  Sun Sep 24 13:16:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 24 Sep 2023 13:16:04 GMT
Subject: RFR: 8316641: VarHandle template classes can share code in the
 base class [v5]
In-Reply-To: 
References: 
 
Message-ID: <9ux2TdHr6rcG2d0HfF-RCts2zot1YNWkLMogg5gvBuQ=.ac5575a4-70e4-4b84-ad67-8ca62cf693ce@github.com>

On Sun, 24 Sep 2023 02:11:50 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:
> 
>   Simplify non-Object array VH

A commit that simplified primitive array VarHandles was split into a separate patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15854#issuecomment-1732567386

From duke at openjdk.org  Sun Sep 24 13:51:23 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 13:51:23 GMT
Subject: RFR: 8315999: Improve Date toString performance [v13]
In-Reply-To: 
References: <3G62I0nr8c3YRI4ltelsZtzUqFZImbzm3VD3Wde_Xz4=.e4d15686-9668-4660-89e0-c696e1b7f0cc@github.com>
 
Message-ID: 

On Wed, 13 Sep 2023 14:22:35 GMT, ???  wrote:

>> improve date toString performance, includes:
>> 
>> java.util.Date.toString
>> java.util.Date.toGMTString
>> java.time.Instant.toString
>> java.time.LocalDate.toString
>> java.time.LocalDateTime.toString
>> java.time.LocalTime.toString
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify LocalDate::getChars

For DateTimeFormatter's parse and format, an effective way to improve performance is to perform fast-path optimization on commonly used patterns. PR #15658 is the fast-path of DateTimeFormatter#format for commonly used patterns.

I also found a way to find the ZoneOffset faster for ZoneIds without daylight saving time, for example Asia/Shanghai.

The combination of these optimizations can make the performance of DateTime's parse and format very fast.

In the baseline code, only Instant#toString uses DateTimeFormatter. The toString Method of Date/LocalDate/LocalDateTime does not use DateTimeFormatter. The current implementation of DateTimeFormatter is not fast enough. After we improve the performance of DateTimeFormatter, we can implement the toString methods of these classes based on DateTimeFormatter.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15658#issuecomment-1732574522

From redestad at openjdk.org  Sun Sep 24 19:30:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 24 Sep 2023 19:30:22 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v6]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Sun, 24 Sep 2023 13:08:58 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:
> 
>   Revert "refactor and cache single conversion FormatSpecifier"
>   
>   This reverts commit 0d977b2febe455f4535e6ee2cb19d3b168d764e3.

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 == '%';

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335234147

From duke at openjdk.org  Sun Sep 24 20:27:53 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 24 Sep 2023 20:27:53 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
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:

  fix logic error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/7b831ab6..155d004f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=05-06

  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 alanb at openjdk.org  Mon Sep 25 06:29:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Sep 2023 06:29:10 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 20:03:51 GMT, Naoto Sato  wrote:

>> Fixed the failing (well, false-positive) test case. Made the following changes to the test:
>> 
>> - Corrected the path to the mapping files directory
>> - Made sure to fail if the directory path is incorrect
>> - Took care of `GB18030` alias, which is dynamically derived at runtime
>> - Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
>> - Excluded other failing tests for IBM charsets that do not have map files.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Included the failed directory location in the exception message

I suspect it was setup this way to allow the test tree be zipped up and the tests run without access to the src tree. In any case, the changes look okay, although a bit fragile to be reaching into the make/data tree for mapping data.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15807#pullrequestreview-1641399005

From azafari at openjdk.org  Mon Sep 25 07:34:49 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 25 Sep 2023 07:34:49 GMT
Subject: RFR: 8314438: NMT: Performance benchmarks are needed to have a
 baseline for comparison of improvements
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 6 Sep 2023 19:56:10 GMT, Gerard Ziemski  wrote:

> The test will not compile for me unless I add:
> 
> `import java.util.concurrent.TimeUnit;`

Sorry, it was removed mistakenly before pushing the code. Now fixed.

> You said `The JSON file can be used for visualising the results.` Can you please explain how to do that exactly?

The [visualizer site](https://jmh.morethan.io) is added to the PR description. The JSON file can be dropped there.

> Is the multithreading mode really useful?

NMT records stack traces for threads in a different way as of other threads. It uses a link list for the former and a static hash table for the latter. I tried to make a more realistic use case of NMT.

> THREADS=2, WITH_THREADS=0
> THREADS=4, WITH_THREADS=0
> THREADS=8, WITH_THREADS=0

The last two rows of the above list are skipped now. Thanks for the comment.

> The tool should look at `NMTOff` first from both runs and verify that they are the same, to prove that the results are useful (there should be no difference)

Which measures should be the same between *both runs*? For `NMT_Off` for example, there are 2 (no of threads= 0,4) measures per method. Consider also, we will have more methods for virtual memory alloc/dealloc tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1709605094
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1709607490
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1709610021
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1709815642
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1719651603

From azafari at openjdk.org  Mon Sep 25 07:34:49 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 25 Sep 2023 07:34:49 GMT
Subject: RFR: 8314438: NMT: Performance benchmarks are needed to have a
 baseline for comparison of improvements
Message-ID: 

A new benchmark for  measuring the NMT overhead in `summary` and `detail` modes.
The tests are run using: 

make CONF=debug test TEST="micro:java.util.NMTBenchmark" MICRO="RESULTS_FORMAT=json"

The results are written to a JSON file that can be visualized using [JMH Visualizer](https://jmh.morethan.io/).

### Notes
A separate [issue](https://bugs.openjdk.org/browse/JDK-8316814) is created for preparing a progfram for validating and analyzing the JMH outputs.
Another separate [issue](https://bugs.openjdk.org/browse/JDK-8316813) is created for measuring the virtual memory tracing parts of NMT.

-------------

Commit messages:
 - realloc and onlyMalloc are added.
 - Sequential part is run only once if WITH_THREADS == 0
 - 8314438: NMT: Performance benchmarks are needed to have a baseline for comparison of improvements

Changes: https://git.openjdk.org/jdk/pull/15563/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15563&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314438
  Stats: 254 lines in 2 files changed: 253 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15563/head:pull/15563

PR: https://git.openjdk.org/jdk/pull/15563

From gziemski at openjdk.org  Mon Sep 25 07:34:49 2023
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 25 Sep 2023 07:34:49 GMT
Subject: RFR: 8314438: NMT: Performance benchmarks are needed to have a
 baseline for comparison of improvements
In-Reply-To: 
References: 
Message-ID: 

On Tue, 5 Sep 2023 07:53:36 GMT, Afshin Zafari  wrote:

> A new benchmark for  measuring the NMT overhead in `summary` and `detail` modes.
> The tests are run using: 
> 
> make CONF=debug test TEST="micro:java.util.NMTBenchmark" MICRO="RESULTS_FORMAT=json"
> 
> The results are written to a JSON file that can be visualized using [JMH Visualizer](https://jmh.morethan.io/).
> 
> ### Notes
> A separate [issue](https://bugs.openjdk.org/browse/JDK-8316814) is created for preparing a progfram for validating and analyzing the JMH outputs.
> Another separate [issue](https://bugs.openjdk.org/browse/JDK-8316813) is created for measuring the virtual memory tracing parts of NMT.

The test will not compile for me unless I add:

`import java.util.concurrent.TimeUnit;`

Marked as reviewed by gziemski (Committer).

These are my results:


Benchmark                                   (N)  (THREADS)  (WITH_THREADS)  Mode  Cnt     Score    Error  Units
NMTBenchmark.NMTDetail.allocateMemory    100000          2               0  avgt   10   130.946 ?  8.761  ms/op
NMTBenchmark.NMTDetail.allocateMemory    100000          2               1  avgt   10     0.399 ?  0.228  ms/op
NMTBenchmark.NMTDetail.allocateMemory    100000          4               0  avgt   10   120.379 ?  8.072  ms/op
NMTBenchmark.NMTDetail.allocateMemory    100000          4               1  avgt   10     0.543 ?  0.207  ms/op
NMTBenchmark.NMTDetail.allocateMemory    100000          8               0  avgt   10   122.144 ?  3.696  ms/op
NMTBenchmark.NMTDetail.allocateMemory    100000          8               1  avgt   10     0.776 ?  0.132  ms/op
NMTBenchmark.NMTDetail.allocateMemory   1000000          2               0  avgt   10  1546.584 ? 24.937  ms/op
NMTBenchmark.NMTDetail.allocateMemory   1000000          2               1  avgt   10     2.757 ?  0.740  ms/op
NMTBenchmark.NMTDetail.allocateMemory   1000000          4               0  avgt   10  1530.738 ? 73.529  ms/op
NMTBenchmark.NMTDetail.allocateMemory   1000000          4               1  avgt   10     2.859 ?  0.624  ms/op
NMTBenchmark.NMTDetail.allocateMemory   1000000          8               0  avgt   10  1609.203 ? 29.717  ms/op
NMTBenchmark.NMTDetail.allocateMemory   1000000          8               1  avgt   10     3.113 ?  0.632  ms/op
NMTBenchmark.NMTOff.allocateMemory       100000          2               0  avgt   10    60.585 ?  4.187  ms/op
NMTBenchmark.NMTOff.allocateMemory       100000          2               1  avgt   10     0.333 ?  0.149  ms/op
NMTBenchmark.NMTOff.allocateMemory       100000          4               0  avgt   10    56.138 ?  2.727  ms/op
NMTBenchmark.NMTOff.allocateMemory       100000          4               1  avgt   10     0.493 ?  0.214  ms/op
NMTBenchmark.NMTOff.allocateMemory       100000          8               0  avgt   10    57.457 ?  2.310  ms/op
NMTBenchmark.NMTOff.allocateMemory       100000          8               1  avgt   10     0.731 ?  0.158  ms/op
NMTBenchmark.NMTOff.allocateMemory      1000000          2               0  avgt   10   815.515 ? 19.232  ms/op
NMTBenchmark.NMTOff.allocateMemory      1000000          2               1  avgt   10     2.674 ?  0.566  ms/op
NMTBenchmark.NMTOff.allocateMemory      1000000          4               0  avgt   10   829.726 ? 31.153  ms/op
NMTBenchmark.NMTOff.allocateMemory      1000000          4               1  avgt   10     2.678 ?  0.652  ms/op
NMTBenchmark.NMTOff.allocateMemory      1000000          8               0  avgt   10   817.929 ? 19.142  ms/op
NMTBenchmark.NMTOff.allocateMemory      1000000          8               1  avgt   10     3.023 ?  0.578  ms/op
NMTBenchmark.NMTSummary.allocateMemory   100000          2               0  avgt   10   101.419 ?  4.231  ms/op
NMTBenchmark.NMTSummary.allocateMemory   100000          2               1  avgt   10     0.329 ?  0.143  ms/op
NMTBenchmark.NMTSummary.allocateMemory   100000          4               0  avgt   10   102.224 ?  3.317  ms/op
NMTBenchmark.NMTSummary.allocateMemory   100000          4               1  avgt   10     0.514 ?  0.230  ms/op
NMTBenchmark.NMTSummary.allocateMemory   100000          8               0  avgt   10   101.127 ?  4.144  ms/op
NMTBenchmark.NMTSummary.allocateMemory   100000          8               1  avgt   10     0.719 ?  0.168  ms/op
NMTBenchmark.NMTSummary.allocateMemory  1000000          2               0  avgt   10  1423.287 ? 56.109  ms/op
NMTBenchmark.NMTSummary.allocateMemory  1000000          2               1  avgt   10     2.682 ?  0.442  ms/op
NMTBenchmark.NMTSummary.allocateMemory  1000000          4               0  avgt   10  1418.999 ? 33.891  ms/op
NMTBenchmark.NMTSummary.allocateMemory  1000000          4               1  avgt   10     2.812 ?  0.510  ms/op
NMTBenchmark.NMTSummary.allocateMemory  1000000          8               0  avgt   10  1431.552 ? 29.915  ms/op
NMTBenchmark.NMTSummary.allocateMemory  1000000          8               1  avgt   10     3.073 ?  0.583  ms/op


You said `The JSON file can be used for visualising the results.` Can you please explain how to do that exactly?

It looks like a good start.

The test took something like 20 minutes for me.

Is the multithreading mode really useful?

And even if we decide that it is, we can probably skip the entries that create the threads, but not actually use them? Ex:

THREADS=2, WITH_THREADS=0
THREADS=4, WITH_THREADS=0
THREADS=8, WITH_THREADS=0

I like it! I do have more follow ups, tough.

I see that we are currently mixing malloc/free. Wouldn't we better served if we separated those as 2 distinct categories? I can imagine a scenario where either malloc or free path could be regressed/improved without affecting the other.

Also, I think we should add realloc to the mix, again keeping it separate. I tried to collapse malloc/realloc into single code path, but it was rejected, mostly on the basis that it would impact the performance - this microbenchmark would be a perfect tool to offer a definitive answer.

Testing the code and looking at the output the microbenchmark produces I think it would be super useful (here or in a follow up issue) to have a python or Java app to quickly run and compare the results to give a user the difference, without having to calculate it by hand (and risk making a mistake)

The tool should look at `NMTOff` first from both runs and verify that they are the same, to prove that the results are useful (there should be no difference)

Only then, if the previous numbers show no change, it should report `NMTSummary`, then `NMTDetail` differences.

I added `usleep(1)` at the beginning of `MallocTracker::record_malloc()` to make sure the microbenchmark catches that, and it does.

> > The tool should look at `NMTOff` first from both runs and verify that they are the same, to prove that the results are useful (there should be no difference)
> 
> Which measures should be the same between _both runs_? For `NMT_Off` for example, there are 2 (no of threads= 0,4) measures per method. Consider also, we will have more methods for virtual memory alloc/dealloc tests.

I think all the available data should be used to verify, so all runs with `NMT_Off`?

This can be done in a followup issue I think?

To me it looks like we have a good starting point, which we can use already (by manually comparing the results), so we are OK to push this in I think.

-------------

Changes requested by gziemski (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15563#pullrequestreview-1614112680
PR Review: https://git.openjdk.org/jdk/pull/15563#pullrequestreview-1629213190
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1709016452
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1709017248
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1709039527
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1711976042
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1717863041
PR Comment: https://git.openjdk.org/jdk/pull/15563#issuecomment-1721458771

From alanb at openjdk.org  Mon Sep 25 07:44:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Sep 2023 07:44:14 GMT
Subject: RFR: 8314438: NMT: Performance benchmarks are needed to have a
 baseline for comparison of improvements
In-Reply-To: 
References: 
Message-ID: 

On Tue, 5 Sep 2023 07:53:36 GMT, Afshin Zafari  wrote:

> A new benchmark for  measuring the NMT overhead in `summary` and `detail` modes.
> The tests are run using: 
> 
> make CONF=debug test TEST="micro:java.util.NMTBenchmark" MICRO="RESULTS_FORMAT=json"
> 
> The results are written to a JSON file that can be visualized using [JMH Visualizer](https://jmh.morethan.io/).
> 
> ### Notes
> A separate [issue](https://bugs.openjdk.org/browse/JDK-8316814) is created for preparing a progfram for validating and analyzing the JMH outputs.
> Another separate [issue](https://bugs.openjdk.org/browse/JDK-8316813) is created for measuring the virtual memory tracing parts of NMT.

test/micro/org/openjdk/bench/java/util/NMTBenchmark.java line 24:

> 22:  */
> 23: 
> 24: package org.openjdk.bench.java.util;

The micros in test/micro/org/openjdk/bench/java/util are usually to test methods in java.util.**. Should this be moved to test/micro/org/openjdk/bench/vm/runtime?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15563#discussion_r1335502840

From pminborg at openjdk.org  Mon Sep 25 08:19:36 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 25 Sep 2023 08:19:36 GMT
Subject: RFR: 8316851: Add @sealedGraph to Executable
Message-ID: 

This PR proposes to add the @sealedGraph tag to `java.lang.reflect.Executable`.

-------------

Commit messages:
 - Add @SealedGraph to Executable

Changes: https://git.openjdk.org/jdk/pull/15897/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15897&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316851
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15897/head:pull/15897

PR: https://git.openjdk.org/jdk/pull/15897

From aturbanov at openjdk.org  Mon Sep 25 09:43:21 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 25 Sep 2023 09:43:21 GMT
Subject: RFR: 8316557: Make fields final in 'sun.util' package
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 18 Sep 2023 14:41:14 GMT, Chen Liang  wrote:

>> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.
>
> src/java.base/share/classes/sun/util/PropertyResourceBundleCharset.java line 71:
> 
>> 69:     private final class PropertiesFileDecoder extends CharsetDecoder {
>> 70: 
>> 71:         private final CharsetDecoder cdUTF_8 = UTF_8.INSTANCE.newDecoder()
> 
> Can be static as well.

I'm not sure. Why do you think so? CharsetDecoder is not thread-safe.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1335644148

From liach at openjdk.org  Mon Sep 25 09:50:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 25 Sep 2023 09:50:12 GMT
Subject: RFR: 8316557: Make fields final in 'sun.util' package
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 25 Sep 2023 09:40:00 GMT, Andrey Turbanov  wrote:

>> src/java.base/share/classes/sun/util/PropertyResourceBundleCharset.java line 71:
>> 
>>> 69:     private final class PropertiesFileDecoder extends CharsetDecoder {
>>> 70: 
>>> 71:         private final CharsetDecoder cdUTF_8 = UTF_8.INSTANCE.newDecoder()
>> 
>> Can be static as well.
>
> I'm not sure. Why do you think so? CharsetDecoder is not thread-safe.

UTF8 decoder does not perform any internal state mutation during decoding; in addition, if this field is static final, the decoder's error actions are published when the class is initialized, while publishing in a final field does not guarantee the internal state of the charset is visible to other threads.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1335653054

From duke at openjdk.org  Mon Sep 25 09:56:19 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 25 Sep 2023 09:56:19 GMT
Subject: RFR: 8316557: Make fields final in 'sun.util' package
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 25 Sep 2023 09:47:15 GMT, Chen Liang  wrote:

> UTF8 decoder does not perform any internal state mutation during decoding; 

Are you sure? I think `CharsetDecoder::decode` will modify the `status` field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1335660344

From liach at openjdk.org  Mon Sep 25 10:07:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 25 Sep 2023 10:07:12 GMT
Subject: RFR: 8316557: Make fields final in 'sun.util' package
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 25 Sep 2023 09:53:47 GMT, Glavo  wrote:

>> UTF8 decoder does not perform any internal state mutation during decoding; in addition, if this field is static final, the decoder's error actions are published when the class is initialized, while publishing in a final field does not guarantee the internal state of the charset is visible to other threads.
>
>> UTF8 decoder does not perform any internal state mutation during decoding; 
> 
> Are you sure? I think `CharsetDecoder::decode` will modify the `status` field.

right, it does have a `state` field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1335672130

From alanb at openjdk.org  Mon Sep 25 10:07:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Sep 2023 10:07:13 GMT
Subject: RFR: 8316557: Make fields final in 'sun.util' package
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Mon, 25 Sep 2023 10:04:13 GMT, Chen Liang  wrote:

>>> UTF8 decoder does not perform any internal state mutation during decoding; 
>> 
>> Are you sure? I think `CharsetDecoder::decode` will modify the `status` field.
>
> right, it does have a `state` field.

CharsetDecoder is specified to be not safe for use by multiple concurrent threads, would be too fragile to assume behavior of a specific implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1335672904

From redestad at openjdk.org  Mon Sep 25 10:09:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 25 Sep 2023 10:09:22 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Sun, 24 Sep 2023 20:27:53 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:
> 
>   fix logic error

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.

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.

-------------

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1641781843
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335667901

From duke at openjdk.org  Mon Sep 25 11:39:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 25 Sep 2023 11:39:13 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: <8BVBi-R2HrSUTxkD9FI03wPKm0-22HeSX0xadLZoIi4=.d0021a5c-3c4d-4f93-84a8-88a13ebb8e7e@github.com>

On Sun, 24 Sep 2023 20:27:53 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:
> 
>   fix logic error

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1733490226

From redestad at openjdk.org  Mon Sep 25 11:49:18 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 25 Sep 2023 11:49:18 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
In-Reply-To: <8BVBi-R2HrSUTxkD9FI03wPKm0-22HeSX0xadLZoIi4=.d0021a5c-3c4d-4f93-84a8-88a13ebb8e7e@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
 <8BVBi-R2HrSUTxkD9FI03wPKm0-22HeSX0xadLZoIi4=.d0021a5c-3c4d-4f93-84a8-88a13ebb8e7e@github.com>
Message-ID: 

On Mon, 25 Sep 2023 11:36:10 GMT, ???  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 azafari at openjdk.org  Mon Sep 25 11:54:36 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 25 Sep 2023 11:54:36 GMT
Subject: RFR: 8314438: NMT: Performance benchmarks are needed to have a
 baseline for comparison of improvements [v2]
In-Reply-To: 
References: 
Message-ID: 

> A new benchmark for  measuring the NMT overhead in `summary` and `detail` modes.
> The tests are run using: 
> 
> make CONF=debug test TEST="micro:java.util.NMTBenchmark" MICRO="RESULTS_FORMAT=json"
> 
> The results are written to a JSON file that can be visualized using [JMH Visualizer](https://jmh.morethan.io/).
> 
> ### Notes
> A separate [issue](https://bugs.openjdk.org/browse/JDK-8316814) is created for preparing a progfram for validating and analyzing the JMH outputs.
> Another separate [issue](https://bugs.openjdk.org/browse/JDK-8316813) is created for measuring the virtual memory tracing parts of NMT.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  new benchmark moved to vm/runtime folder.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15563/files
  - new: https://git.openjdk.org/jdk/pull/15563/files/f6a153fc..e153c0db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15563&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15563&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15563/head:pull/15563

PR: https://git.openjdk.org/jdk/pull/15563

From azafari at openjdk.org  Mon Sep 25 11:57:16 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 25 Sep 2023 11:57:16 GMT
Subject: RFR: 8314438: NMT: Performance benchmarks are needed to have a
 baseline for comparison of improvements [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 25 Sep 2023 07:41:24 GMT, Alan Bateman  wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   new benchmark moved to vm/runtime folder.
>
> test/micro/org/openjdk/bench/java/util/NMTBenchmark.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: package org.openjdk.bench.java.util;
> 
> The micros in test/micro/org/openjdk/bench/java/util are usually to test methods in java.util.**. Should this be moved to test/micro/org/openjdk/bench/vm/runtime?

Thanks for the comment. 
Fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15563#discussion_r1335779697

From alanb at openjdk.org  Mon Sep 25 12:01:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Sep 2023 12:01:16 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 22:46:43 GMT, Brian Burkhalter  wrote:

>> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316000: Align the spec and return verbiage

I looked at the latest update (8189784a) and have two suggestions

1. Revert the method descriptions to what you had in the previous version (8640decd). That makes it clear it returns the value of the parameter when the platform doesn't support file permissions.

2. In the return description, make it clear that the method fails if the user does not have permission to change the access permissions, or the platform supports file permissions but the underlying file system does not implement the read/whatever permission.

I think that will cover the 2x2 cases of platform vs. underlying file permissions that the previous iterations grappled with.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15673#issuecomment-1733521012

From duke at openjdk.org  Mon Sep 25 12:06:52 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 25 Sep 2023 12:06:52 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v8]
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: <4noA-egaRq6i4Lhu46xK4k7msZAi_e8ObyYFMHtomTk=.ea4788b1-5b9e-4219-8449-119c174b39d9@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)

??? has updated the pull request incrementally with one additional commit since the last revision:

  remove unused code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/155d004f..f85b9d47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=06-07

  Stats: 15 lines in 1 file changed: 0 ins; 15 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 dl at openjdk.org  Mon Sep 25 12:12:11 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 25 Sep 2023 12:12:11 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v36]
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:

  Fix and improve windowing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/907ad02b..a7ff60e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=34-35

  Stats: 221 lines in 1 file changed: 64 ins; 53 del; 104 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  Mon Sep 25 12:23:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 25 Sep 2023 12:23:17 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
 <8BVBi-R2HrSUTxkD9FI03wPKm0-22HeSX0xadLZoIi4=.d0021a5c-3c4d-4f93-84a8-88a13ebb8e7e@github.com>
 
Message-ID: <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.a4abcb81-f3fb-4e40-8079-7862dd47e16d@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 liach at openjdk.org  Mon Sep 25 12:37:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 25 Sep 2023 12:37:45 GMT
Subject: RFR: 8311906: Race condition in String constructor
Message-ID: 

In the constructor of String, many locations the user-supplied byte or char arrays are read multiple times with a plain memory access; if a user previously wrote to one of such locations out of happens-before order, distinct plain memory reads may result in different unanticipated values.

The main problem caused by such error is that String constructor may incorrectly produce a UTF16 coder string with all-LATIN1 compatible characters when `COMPACT_STRING` is true, which breaks the contract of String. (The error can happen the other way around, but the resulting LATIN1 string is valid; this patch does not address that.)

Thus, I modified the String data compression for non-trusted arrays: a LATIN1 compression first-pass is still done, but if the first compression fails, a second compression pass is done on a trusted (that is, copied from the original data) data where reading would be consistent. The approach takes a toll on UTF16 string construction time, but should not be more costly memory-wise.

A separate routine to decode UTF8 in String constructor that takes byte encoding has the same multi-read problem, that the old `offset--` leads to a problematic double read. This is resolved by copying the data to decode to a local array at first instead of reading from the user-provided byte array. This fix also costs more runtime but at no extra memory cost.

Internal APIs such as newStringNoRepl are not guarded by this patch, as they are already trusted to be immutable and unshared.

`test/jdk/java/lang/String` tests pass. More testing is needed to see if there are other edge cases not covered.

Please review and don't hesitate to critique my approach and patch.

-------------

Commit messages:
 - 8311906 - fix utf16 first

Changes: https://git.openjdk.org/jdk/pull/15902/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15902&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311906
  Stats: 87 lines in 3 files changed: 48 ins; 10 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/15902.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15902/head:pull/15902

PR: https://git.openjdk.org/jdk/pull/15902

From alanb at openjdk.org  Mon Sep 25 12:37:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Sep 2023 12:37:45 GMT
Subject: RFR: 8311906: Race condition in String constructor
In-Reply-To: 
References: 
Message-ID: 

On Mon, 25 Sep 2023 12:28:40 GMT, Chen Liang  wrote:

> In the constructor of String, many locations the user-supplied byte or char arrays are read multiple times with a plain memory access; if a user previously wrote to one of such locations out of happens-before order, distinct plain memory reads may result in different unanticipated values.
> 
> The main problem caused by such error is that String constructor may incorrectly produce a UTF16 coder string with all-LATIN1 compatible characters when `COMPACT_STRING` is true, which breaks the contract of String. (The error can happen the other way around, but the resulting LATIN1 string is valid; this patch does not address that.)
> 
> Thus, I modified the String data compression for non-trusted arrays: a LATIN1 compression first-pass is still done, but if the first compression fails, a second compression pass is done on a trusted (that is, copied from the original data) data where reading would be consistent. The approach takes a toll on UTF16 string construction time, but should not be more costly memory-wise.
> 
> A separate routine to decode UTF8 in String constructor that takes byte encoding has the same multi-read problem, that the old `offset--` leads to a problematic double read. This is resolved by copying the data to decode to a local array at first instead of reading from the user-provided byte array. This fix also costs more runtime but at no extra memory cost.
> 
> Internal APIs such as newStringNoRepl are not guarded by this patch, as they are already trusted to be immutable and unshared.
> 
> `test/jdk/java/lang/String` tests pass. More testing is needed to see if there are other edge cases not covered.
> 
> Please review and don't hesitate to critique my approach and patch.

The JBS is assigned to Roger Riggs, he has changes in progress for this so please coordinate to avoid this duplicate effort.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15902#issuecomment-1733621925

From redestad at openjdk.org  Mon Sep 25 12:49:15 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 25 Sep 2023 12:49:15 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v8]
In-Reply-To: <4noA-egaRq6i4Lhu46xK4k7msZAi_e8ObyYFMHtomTk=.ea4788b1-5b9e-4219-8449-119c174b39d9@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 <4noA-egaRq6i4Lhu46xK4k7msZAi_e8ObyYFMHtomTk=.ea4788b1-5b9e-4219-8449-119c174b39d9@github.com>
Message-ID: 

On Mon, 25 Sep 2023 12:06:52 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:
> 
>   remove unused code

A few nits, otherwise I think this looks OK

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1641961236

From redestad at openjdk.org  Mon Sep 25 12:49:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 25 Sep 2023 12:49:22 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Sun, 24 Sep 2023 20:27:53 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:
> 
>   fix logic error

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`

-------------

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

From rriggs at openjdk.org  Mon Sep 25 13:38:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 25 Sep 2023 13:38:18 GMT
Subject: RFR: 8311906: Race condition in String constructor
In-Reply-To: 
References: 
Message-ID: 

On Mon, 25 Sep 2023 12:28:40 GMT, Chen Liang  wrote:

> In the constructor of String, many locations the user-supplied byte or char arrays are read multiple times with a plain memory access; if a user previously wrote to one of such locations out of happens-before order, distinct plain memory reads may result in different unanticipated values.
> 
> The main problem caused by such error is that String constructor may incorrectly produce a UTF16 coder string with all-LATIN1 compatible characters when `COMPACT_STRING` is true, which breaks the contract of String. (The error can happen the other way around, but the resulting LATIN1 string is valid; this patch does not address that.)
> 
> Thus, I modified the String data compression for non-trusted arrays: a LATIN1 compression first-pass is still done, but if the first compression fails, a second compression pass is done on a trusted (that is, copied from the original data) data where reading would be consistent. The approach takes a toll on UTF16 string construction time, but should not be more costly memory-wise.
> 
> A separate routine to decode UTF8 in String constructor that takes byte encoding has the same multi-read problem, that the old `offset--` leads to a problematic double read. This is resolved by copying the data to decode to a local array at first instead of reading from the user-provided byte array. This fix also costs more runtime but at no extra memory cost.
> 
> Internal APIs such as newStringNoRepl are not guarded by this patch, as they are already trusted to be immutable and unshared.
> 
> `test/jdk/java/lang/String` tests pass. More testing is needed to see if there are other edge cases not covered.
> 
> Please review and don't hesitate to critique my approach and patch.

I've been working on something similar and am in the process of fine tuning it to ensure that it is performance neutral both in both allocation rate and cpu time and has little/no impact on either latin1 or UTF16 string codings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15902#issuecomment-1733726939

From abimpoudis at openjdk.org  Mon Sep 25 13:40:07 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 25 Sep 2023 13:40:07 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, 
 instanceof, and switch (Preview)
Message-ID: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@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

-------------

Commit messages:
 - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303374
  Stats: 2293 lines in 29 files changed: 2186 ins; 16 del; 91 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 Sep 25 13:43:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 25 Sep 2023 13:43:11 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v9]
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:

  remove unused code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/f85b9d47..6be4d46c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 3 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 Sep 25 13:45:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 25 Sep 2023 13:45:17 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
 
Message-ID: <0e11fGG0_saPD3r-i7gy3jn1Fs5nXGUEi98r9M9NlhU=.3c56e1ff-2f84-4d5c-8299-b6c1393e23f2@github.com>

On Mon, 25 Sep 2023 12:28:06 GMT, Claes Redestad  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix logic error
>
> 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++) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1335909991

From liach at openjdk.org  Mon Sep 25 13:48:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 25 Sep 2023 13:48:15 GMT
Subject: RFR: 8311906: Race condition in String constructor
In-Reply-To: 
References: 
Message-ID: 

On Mon, 25 Sep 2023 12:28:40 GMT, Chen Liang  wrote:

> In the constructor of String, many locations the user-supplied byte or char arrays are read multiple times with a plain memory access; if a user previously wrote to one of such locations out of happens-before order, distinct plain memory reads may result in different unanticipated values.
> 
> The main problem caused by such error is that String constructor may incorrectly produce a UTF16 coder string with all-LATIN1 compatible characters when `COMPACT_STRING` is true, which breaks the contract of String. (The error can happen the other way around, but the resulting LATIN1 string is valid; this patch does not address that.)
> 
> Thus, I modified the String data compression for non-trusted arrays: a LATIN1 compression first-pass is still done, but if the first compression fails, a second compression pass is done on a trusted (that is, copied from the original data) data where reading would be consistent. The approach takes a toll on UTF16 string construction time, but should not be more costly memory-wise.
> 
> A separate routine to decode UTF8 in String constructor that takes byte encoding has the same multi-read problem, that the old `offset--` leads to a problematic double read. This is resolved by copying the data to decode to a local array at first instead of reading from the user-provided byte array. This fix also costs more runtime but at no extra memory cost.
> 
> Internal APIs such as newStringNoRepl are not guarded by this patch, as they are already trusted to be immutable and unshared.
> 
> `test/jdk/java/lang/String` tests pass. More testing is needed to see if there are other edge cases not covered.
> 
> Please review and don't hesitate to critique my approach and patch.

A prototype I thought of was to modify array compression to return the stopping index + the bad 2-byte value, packed like lengthCoder used by String concatenation, at that index to avoid double-reads, but was not sure how to modify hotspot code to accomplish that. As long as we have a valid 2-byte value into the UTF16 value array, we can prevent constructing invalid Strings.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15902#issuecomment-1733744966

From rriggs at openjdk.org  Mon Sep 25 14:26:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 25 Sep 2023 14:26:18 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v21]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: <4JmSZuWs0BWHa_precJ3I4-wQQlhvZ98OlJtcPXB4XM=.b8382012-c280-4681-8c1d-1aaeeb2ec2fb@github.com>

On Sun, 24 Sep 2023 02:46:38 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore StringUTF16.getChars(int,int,int,byte[]) and StringUTF16.getChars(long,int,int,byte[])

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-1733814668

From duke at openjdk.org  Mon Sep 25 14:28:56 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 25 Sep 2023 14:28:56 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v10]
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:

  refactor for review & remove comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/6be4d46c..ba4660a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=08-09

  Stats: 27 lines in 2 files changed: 0 ins; 19 del; 8 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 abimpoudis at openjdk.org  Mon Sep 25 15:04:00 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 25 Sep 2023 15:04:00 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns
Message-ID: 

8315532: Compiler Implementation for Unnamed Variables and Patterns

-------------

Commit messages:
 - 8315532: Compiler Implementation for Unnamed Variables and Patterns

Changes: https://git.openjdk.org/jdk/pull/15649/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315532
  Stats: 176 lines in 34 files changed: 37 ins; 37 del; 102 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 jvernee at openjdk.org  Mon Sep 25 15:05:19 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 25 Sep 2023 15:05:19 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v25]
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:

  Split note about byte order/alignment out of header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/1c24f33e..49bdd953

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=23-24

  Stats: 83 lines in 1 file changed: 42 ins; 2 del; 39 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  Mon Sep 25 15:05:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 25 Sep 2023 15:05:21 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <17Hdk-QZiKVqpNzEV_v3vhd6uqDTdIdNpIYQmbETPNc=.ee3d0448-684d-4e67-abcf-f2af95bd1ea5@github.com>
References: 
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 
 
 
 
 
 <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
 <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>
 
 <17Hdk-QZiKVqpNzEV_v3vhd6uqDTdIdNpIY
 QmbETPNc=.ee3d0448-684d-4e67-abcf-f2af95bd1ea5@github.com>
Message-ID: 

On Fri, 22 Sep 2023 16:58:05 GMT, Maurizio Cimadamore  wrote:

>> Here you go: https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,long)
>
> Ok, now I'm more convinced that the method summary really does look bad (or worse, compared to 20).
> 
> For instance [allocateFrom](https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout.OfByte,byte...):
> 
> 
> Returns a new memory segment with a byteSize() initialized with the provided E byte elements as specified by the provided layout (i.e. byte ordering, alignment and size).
> 
> 
> (same is true for all the other array-accepting `allocateFrom` methods). This should be simplified to:
> 
> 
> Returns a new memory segment initialized with the elements in the provided byte array.
> 
> (then, if we want to say that the initialization honors the endianness of the provided layout, we can do so in a followup para, but the method summary should be simple).
> 
> So, once all the array-accepting methods are fixed, the segment-accepting `allocateFrom` needs to be simplified to:
> 
> 
> Returns a new memory segment initialized with the contents of the provided segment.

I've updated the 'header' of these methods, and instead added a more elaborated comment in a second paragraph. The single value `allocateFrom` methods had the same issue. I fixed those as well See: https://github.com/openjdk/jdk/pull/15103/commits/49bdd953eaed8732b59a803516355abc8df31fa3

Here is the re-generated javadoc: https://cr.openjdk.org/~jvernee/FFM_22_PR/v2/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout.OfInt,int...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1336017587

From dl at openjdk.org  Mon Sep 25 15:06:20 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 25 Sep 2023 15:06:20 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v37]
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:

  Ensure publishabliity on resize

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/a7ff60e9..bc9cc049

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=35-36

  Stats: 7 lines in 1 file changed: 3 ins; 2 del; 2 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 jvernee at openjdk.org  Mon Sep 25 15:09:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 25 Sep 2023 15:09:09 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v26]
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:

  Tweak support for restricted methods
  
  Reviewed-by: jvernee, pminborg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/49bdd953..82a91258

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=24-25

  Stats: 34 lines in 10 files changed: 3 ins; 11 del; 20 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 dl at openjdk.org  Mon Sep 25 15:09:41 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 25 Sep 2023 15:09:41 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v38]
In-Reply-To: 
References: 
Message-ID: <-ykaAnrPramqe5g88wc4qQVvCY5vUgV93trA_q4T5LM=.0075bd02-afe7-4ecb-93aa-ce3f9a0003a7@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 85 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Ensure publishabliity on resize
 - Fix and improve windowing
 - Accommodate parallelism 0
 - Merge branch 'openjdk:master' into JDK-8288899
 - Fix header; don't shadow park state
 - Merge branch 'openjdk:master' into JDK-8288899
 - Revert Unsafe; reduce signal stalls
 - Merge branch 'openjdk:master' into JDK-8288899
 - Strengthen translation of getAndX atomics; revert or adapt FJP accordingly
 - ... and 75 more: https://git.openjdk.org/jdk/compare/d600df38...8e6b0be1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/bc9cc049..8e6b0be1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=36-37

  Stats: 28727 lines in 578 files changed: 15514 ins; 10476 del; 2737 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 liach at openjdk.org  Mon Sep 25 15:45:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 25 Sep 2023 15:45:12 GMT
Subject: RFR: 8311906: Race condition in String constructor
In-Reply-To: 
References: 
Message-ID: 

On Mon, 25 Sep 2023 12:28:40 GMT, Chen Liang  wrote:

> In the constructor of String, many locations the user-supplied byte or char arrays are read multiple times with a plain memory access; if a user previously wrote to one of such locations out of happens-before order, distinct plain memory reads may result in different unanticipated values.
> 
> The main problem caused by such error is that String constructor may incorrectly produce a UTF16 coder string with all-LATIN1 compatible characters when `COMPACT_STRING` is true, which breaks the contract of String. (The error can happen the other way around, but the resulting LATIN1 string is valid; this patch does not address that.)
> 
> Thus, I modified the String data compression for non-trusted arrays: a LATIN1 compression first-pass is still done, but if the first compression fails, a second compression pass is done on a trusted (that is, copied from the original data) data where reading would be consistent. The approach takes a toll on UTF16 string construction time, but should not be more costly memory-wise.
> 
> A separate routine to decode UTF8 in String constructor that takes byte encoding has the same multi-read problem, that the old `offset--` leads to a problematic double read. This is resolved by copying the data to decode to a local array at first instead of reading from the user-provided byte array. This fix also costs more runtime but at no extra memory cost.
> 
> Internal APIs such as newStringNoRepl are not guarded by this patch, as they are already trusted to be immutable and unshared.
> 
> `test/jdk/java/lang/String` tests pass. More testing is needed to see if there are other edge cases not covered.
> 
> Please review and don't hesitate to critique my approach and patch.

A side comment: I don't think it's problematic if we incorrectly create a LATIN1 String (such as by downcasting a char to byte), for such a String is valid and it's user's fault (for not publishing their writes to the array in happens-before order). We only think about avoiding writing a values array with no significant byte: we can just write any non-trivial 2-byte into UTF16 to make it valid, and that's why I'm looking for compress to return a `twoByte << 32 | consumedLength`. Such a task of writing a 2-byte should be easy to accomplish.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15902#issuecomment-1733990052

From avoitylov at openjdk.org  Mon Sep 25 16:00:49 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 25 Sep 2023 16:00:49 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are disabled
 after JDK-8302163
Message-ID: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>

test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.

Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

-------------

Commit messages:
 - JDK-8316879 implementation

Changes: https://git.openjdk.org/jdk/pull/15906/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316879
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15906/head:pull/15906

PR: https://git.openjdk.org/jdk/pull/15906

From darcy at openjdk.org  Mon Sep 25 16:33:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 25 Sep 2023 16:33:13 GMT
Subject: RFR: 8316851: Add @sealedGraph to Executable
In-Reply-To: 
References: 
Message-ID: 

On Mon, 25 Sep 2023 08:11:48 GMT, Per Minborg  wrote:

> This PR proposes to add the @sealedGraph tag to `java.lang.reflect.Executable`.

Please update the copyright year before pushing.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15897#pullrequestreview-1642582767

From duke at openjdk.org  Mon Sep 25 16:41:28 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Mon, 25 Sep 2023 16:41:28 GMT
Subject: Integrated: 8271268: Fix Javadoc links for Stream.mapMulti
In-Reply-To: 
References: 
Message-ID: 

On Mon, 18 Sep 2023 18:09:57 GMT, Mourad Abbay  wrote:

> Fix Javadoc links for Stream.mapMulti, Stream.MapMultiInt, Stream.mapMultiToInt, Stream.mapMultiToLong and Stream.mapMultiToDouble.

This pull request has now been integrated.

Changeset: afa48333
Author:    Mourad Abbay 
Committer: Paul Sandoz 
URL:       https://git.openjdk.org/jdk/commit/afa48333ab9fb64fb45e6c8d00e8d5cf732268be
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8271268: Fix Javadoc links for Stream.mapMulti

Reviewed-by: liach, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/15794

From mcimadamore at openjdk.org  Mon Sep 25 16:47:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 16:47:26 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v26]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 25 Sep 2023 15:09: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:
> 
>   Tweak support for restricted methods
>   
>   Reviewed-by: jvernee, pminborg

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 336:

> 334:      * {@return a new memory segment initialized with the contents of the provided segment.}
> 335:      * 

> 336:      * The size of the allocated memory segment is the {@code elementLayout.byteSize() * elementCount}.

Suggestion:

     * The size of the allocated memory segment is {@code elementLayout.byteSize() * elementCount}.

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 378:

> 376:      * {@return a new memory segment initialized with the elements in the provided byte array.}
> 377:      * 

> 378:      * The size of the allocated memory segment is the {@code elementLayout.byteSize() * elements.length}.

Suggestion:

     * The size of the allocated memory segment is {@code elementLayout.byteSize() * elements.length}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1336148784
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1336149140

From mcimadamore at openjdk.org  Mon Sep 25 16:47:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 16:47:28 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v26]
In-Reply-To: 
References: 
 
 
Message-ID: <7g-pbFrnyMYtXK4894kdPWvsXJ79YdIp538CXAAiswU=.b65efe29-615e-45c3-abab-bd44d4c91bca@github.com>

On Mon, 25 Sep 2023 16:44:01 GMT, Maurizio Cimadamore  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak support for restricted methods
>>   
>>   Reviewed-by: jvernee, pminborg
>
> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 378:
> 
>> 376:      * {@return a new memory segment initialized with the elements in the provided byte array.}
>> 377:      * 

>> 378:      * The size of the allocated memory segment is the {@code elementLayout.byteSize() * elements.length}.
> 
> Suggestion:
> 
>      * The size of the allocated memory segment is {@code elementLayout.byteSize() * elements.length}.

Here and also in all the other array-accepting methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1336149494

From jvernee at openjdk.org  Mon Sep 25 16:54:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 25 Sep 2023 16:54:10 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
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:

  fix typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/82a91258..0244845a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=25-26

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 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 sviswanathan at openjdk.org  Mon Sep 25 16:54:37 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 25 Sep 2023 16:54:37 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: 
References: 
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 
Message-ID: 

On Wed, 30 Aug 2023 02:01:38 GMT, Vladimir Kozlov  wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up parameters passed to arrayPartition; update the check to load library
>
> Good. Thank you.

@vnkozlov Vamsi has approval from Paul on the Java side. He has also implemented all the review comments on the build changes from Eric and Magnus. Could you please take a relook at the PR and let us know if you are ok with the changes made since your last review. This has been a long journey. We are looking forward to your review. Thanks a lot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1734126795

From simonis at openjdk.org  Mon Sep 25 17:08:13 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 25 Sep 2023 17:08:13 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: <71Ou16XncKZUJgtDhsrjzjRX-RjjK-LIVDdIKcyUQMs=.7e1e75b2-dcec-47e2-85c1-421aca439e1c@github.com>

On Mon, 25 Sep 2023 15:52:12 GMT, Aleksei Voitylov  wrote:

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

Nice catch, but I don't think your current fix is correct:

src/java.base/share/classes/java/lang/String.java line 2159:

> 2157:             return false;
> 2158:         }
> 2159:         // Any strings match if length < 0

I don't think this fix works, because the specification says:

*The result is false if and only if at least one of the following is true:*
- `toffset` is negative.
- `ooffset` is negative.
- `toffset+len` is greater than the length of this String object.
- `ooffset+len` is greater than the length of the other argument.
- There is some nonnegative integer `k` less than `len` such that: `this.charAt(toffset + k) != other.charAt(ooffset + k)`

Now consider `"12345".regionMatches(10, "012345", 1, -3)`

With the current implementation, the call returns `false` because `toffset + len` == `10 + (-3)` == 7 > 5 == `"12345".length()`. With your fix, the call will succeed because `len` == `-3` < `0`.

-------------

Changes requested by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15906#pullrequestreview-1642643067
PR Review Comment: https://git.openjdk.org/jdk/pull/15906#discussion_r1336170810

From jlahoda at openjdk.org  Mon Sep 25 17:13:19 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 25 Sep 2023 17:13:19 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns
In-Reply-To: 
References: 
Message-ID: 

On Sat, 9 Sep 2023 00:02:20 GMT, Aggelos Biboudis  wrote:

> This PR finalizes the feature of unnamed variables and patterns.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change requires CSR request [JDK-8315851](https://bugs.openjdk.org/browse/JDK-8315851) to be approved
> 
> 
> 
> ### Reviewing
> 
Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649` \
> `$ git checkout pull/15649`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/15649` \
> `$ git pull https://git.openjdk.org/jdk.git pull/15649/head`
> 
> 

> 
Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 15649`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 15649`
> 
> 

> 
Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/15649.diff
> 
> 

> 
> 
> ### Webrev
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/15649#issuecomment-1733906010)

Overall, looks reasonable to me. A few comments/suggestions for your consideration inline.

test/langtools/tools/javac/T8314423.java line 5:

> 3:  * @bug 8314423
> 4:  * @summary Multiple patterns without unnamed variables
> 5:  * @compile T8314423.java

I think I would keep the existing `@compile` as well, with `--release 21`, to verify the source level checks are working.

test/langtools/tools/javac/diags/examples/UnderscoreAsIdentifierError.java line 26:

> 24: // key: compiler.err.underscore.as.identifier
> 25: // key: compiler.warn.source.no.system.modules.path
> 26: // options: -source 20

Nit: either `-Xlint:-options -source 21`, or `--release 21`, and drop the `warn.source.no.system.modules.path`.

test/langtools/tools/javac/diags/examples/UnderscoreInLambdaExpression.java line 24:

> 22:  */
> 23: 
> 24: // options: -Xlint:preview

`-Xlint:preview` is probably unnecessary here.

test/langtools/tools/javac/diags/examples/UseOfUnderscoreNotAllowedWithBrackets.java line 25:

> 23: 
> 24: // key: compiler.err.use.of.underscore.not.allowed.with.brackets
> 25: // options: -Xlint:preview

The `-Xlint:preview` is probably unnecessary here.

test/langtools/tools/javac/lambda/IdentifierTest.java line 7:

> 5:  * @summary Test generation of warnings when '_' is used an identifier
> 6:  * @compile/fail/ref=IdentifierTest8.out --release 8 -Werror -XDrawDiagnostics -Xlint:-options IdentifierTest.java
> 7:  * @compile/fail/ref=IdentifierTest9.out -XDrawDiagnostics IdentifierTest.java

Note here we are using `ref=IdentifierTest9.out`, but there's no `--release 9` (or `--release 21`). So, it is the same as the next line. I think it would be useful if one of these lines used `--release 21` - even if the outputs are the same.

test/langtools/tools/javac/lambda/IdentifierTest9.out line 33:

> 31: IdentifierTest.java:152:17: compiler.err.use.of.underscore.not.allowed
> 32: IdentifierTest.java:158:16: compiler.err.use.of.underscore.not.allowed.with.brackets
> 33: IdentifierTest.java:160:25: compiler.err.use.of.underscore.not.allowed

Note the errors are like:

/home/jlahoda/src/jdk/jdk2/test/langtools/tools/javac/lambda/IdentifierTest.java:160: error: as of release 21, the underscore keyword '_' is only allowed to declare
        for(String _s : _ ) {
                        ^
  unnamed patterns, local variables, exception parameters or lambda parameters


At least the release version should be updated, but to not let the message to be broken into two lines like this. Maybe produce a top-level diagnostic along the line of "underscore not allowed here" with sub-diagnostic with the details (which then can (maybe?) span multiple lines).

Also, the wording sounds to me like if there was a restriction in JDK 22, while underscore is actually permitted on more places than before.

So, maybe something like:


underscore not allowed here
as of release 9, ''_'' is a keyword, and may not be used as an identifier
as of release 21, ''_'' can be used as a name in the declaration of unnamed patterns, local variables, exception parameters or lambda parameters

?
Just an idea.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15649#pullrequestreview-1642635025
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336168133
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336173607
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336171867
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336169144
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336171079
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336165928

From naoto at openjdk.org  Mon Sep 25 18:08:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 25 Sep 2023 18:08:13 GMT
Subject: Integrated: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing
In-Reply-To: 
References: 
Message-ID: 

On Tue, 19 Sep 2023 01:01:14 GMT, Naoto Sato  wrote:

> Fixed the failing (well, false-positive) test case. Made the following changes to the test:
> 
> - Corrected the path to the mapping files directory
> - Made sure to fail if the directory path is incorrect
> - Took care of `GB18030` alias, which is dynamically derived at runtime
> - Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
> - Excluded other failing tests for IBM charsets that do not have map files.

This pull request has now been integrated.

Changeset: e3201d1d
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/e3201d1d13433857a1b34ff0ca93f9ae1a4e22aa
Stats:     20 lines in 2 files changed: 14 ins; 2 del; 4 mod

8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is spuriously passing

Reviewed-by: jlu, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15807

From simonis at openjdk.org  Mon Sep 25 18:34:34 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 25 Sep 2023 18:34:34 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

On Mon, 25 Sep 2023 15:52:12 GMT, Aleksei Voitylov  wrote:

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

Looks good.

PS: I specifically like the "*Looks simple and harmless*" [comment on the PR of the original change](https://github.com/openjdk/jdk/pull/12528#pullrequestreview-1295839377) :)

-------------

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15906#pullrequestreview-1642774005

From simonis at openjdk.org  Mon Sep 25 18:37:54 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 25 Sep 2023 18:37:54 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

On Mon, 25 Sep 2023 15:52:12 GMT, Aleksei Voitylov  wrote:

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

Might be a good idea to add a simple regressions test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1734269182

From bpb at openjdk.org  Mon Sep 25 20:25:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 25 Sep 2023 20:25:41 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v6]
In-Reply-To: 
References: 
Message-ID: <5rRDV3XB9ATOGDFGIwj21uA6gkVF7NDj8eRuvYbpw5I=.2f2d93b8-d9d0-4329-9c96-2540bbaa2963@github.com>

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316000: Revert specification verbiage and modify @return description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15673/files
  - new: https://git.openjdk.org/jdk/pull/15673/files/8189784a..2ec7d229

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=04-05

  Stats: 30 lines in 1 file changed: 4 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/15673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15673/head:pull/15673

PR: https://git.openjdk.org/jdk/pull/15673

From duke at openjdk.org  Tue Sep 26 02:01:09 2023
From: duke at openjdk.org (Logan Abernathy)
Date: Tue, 26 Sep 2023 02:01:09 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

On Mon, 25 Sep 2023 15:52:12 GMT, Aleksei Voitylov  wrote:

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

Marked as reviewed by M4ximumPizza at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15906#pullrequestreview-1643216765

From egahlin at openjdk.org  Tue Sep 26 05:11:36 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 26 Sep 2023 05:11:36 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket events
Message-ID: 

Hi,

The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 

Testing: jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Socket write event
 - Initial

Changes: https://git.openjdk.org/jdk/pull/15908/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15908&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316927
  Stats: 47 lines in 4 files changed: 20 ins; 6 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/15908.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15908/head:pull/15908

PR: https://git.openjdk.org/jdk/pull/15908

From alanb at openjdk.org  Tue Sep 26 05:45:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Sep 2023 05:45:09 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

On Mon, 25 Sep 2023 15:52:12 GMT, Aleksei Voitylov  wrote:

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

As Volker said, a test should be added. Also please have a maintainer working in this area review it too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1734864795

From pminborg at openjdk.org  Tue Sep 26 06:07:02 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 26 Sep 2023 06:07:02 GMT
Subject: RFR: 8316851: Add @sealedGraph to Executable [v2]
In-Reply-To: 
References: 
Message-ID: <-lS3qkFSrcaGSaRwC1P-ZvXyZVhuWbxFGjw6cwzJcig=.c0e836c8-f239-4e51-9b00-32ddbd592206@github.com>

> This PR proposes to add the @sealedGraph tag to `java.lang.reflect.Executable`.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15897/files
  - new: https://git.openjdk.org/jdk/pull/15897/files/6b27cf5a..e0657fbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15897&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15897&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15897.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15897/head:pull/15897

PR: https://git.openjdk.org/jdk/pull/15897

From pminborg at openjdk.org  Tue Sep 26 06:07:04 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 26 Sep 2023 06:07:04 GMT
Subject: Integrated: 8316851: Add @sealedGraph to Executable
In-Reply-To: 
References: 
Message-ID: 

On Mon, 25 Sep 2023 08:11:48 GMT, Per Minborg  wrote:

> This PR proposes to add the @sealedGraph tag to `java.lang.reflect.Executable`.

This pull request has now been integrated.

Changeset: 9e6cb620
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/9e6cb620486ac7b0adaefeb2000babf3ea31207f
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8316851: Add @sealedGraph to Executable

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/15897

From alanb at openjdk.org  Tue Sep 26 07:43:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Sep 2023 07:43:12 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v6]
In-Reply-To: <5rRDV3XB9ATOGDFGIwj21uA6gkVF7NDj8eRuvYbpw5I=.2f2d93b8-d9d0-4329-9c96-2540bbaa2963@github.com>
References: 
 <5rRDV3XB9ATOGDFGIwj21uA6gkVF7NDj8eRuvYbpw5I=.2f2d93b8-d9d0-4329-9c96-2540bbaa2963@github.com>
Message-ID: 

On Mon, 25 Sep 2023 20:25:41 GMT, Brian Burkhalter  wrote:

>> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316000: Revert specification verbiage and modify @return description

The update in 2ec7d229 is good. I think we still have an issue with return description not taking account of the case where the platform doesn't support the operation, e.g. setReadable says that it returns "true if and only if the operation succeeded". This could be addressed by starting with the return description with something like "Where the platforms support setting a file's read permission ..." but that opens the door to further expanding for the case where file permissions aren't supported. I think I'm leaning towards expanding the methods descriptions to cover all the cases so that the return description can be removed to saying that it returns true when the operation succeeds, false if it fails, and the value of the parameter when not supported by the platform.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15673#issuecomment-1734998364

From asotona at openjdk.org  Tue Sep 26 09:40:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Sep 2023 09:40:26 GMT
Subject: RFR: 8308753: Class-File API transition to Preview
Message-ID: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@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

-------------

Commit messages:
 - fixed tests
 - rename of Classfile* to ClassFile*
 - fixed javac tests
 - temporary reverted conversion of tests to Classfile API due incompatibility with enabled preview
 - build and tests fixes
 - Merge branch 'master' into JDK-8308753-preview
 - added jvms link to DynamicConstantPoolEntry
 - fixed EnclosingMethodAttribute javadoc
 - documented constraints of builder and factory methods
 - added package info paragraph "Consistency checks, syntax checks and verification"
 - ... and 310 more: https://git.openjdk.org/jdk/compare/913e43fe...6594ee74

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308753
  Stats: 28985 lines in 760 files changed: 12993 ins; 12505 del; 3487 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 mbaesken at openjdk.org  Tue Sep 26 09:48:37 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Sep 2023 09:48:37 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547
Message-ID: 

AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.

-------------

Commit messages:
 - JDK-8316897

Changes: https://git.openjdk.org/jdk/pull/15916/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15916&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316897
  Stats: 60 lines in 11 files changed: 60 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15916/head:pull/15916

PR: https://git.openjdk.org/jdk/pull/15916

From ihse at openjdk.org  Tue Sep 26 09:57:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 26 Sep 2023 09:57:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <9Mzvela_6bk-RbrzuwgtAh8YBykhV8Gso6Lg2oX37qY=.1fd2a73f-9272-497c-814e-9ba690feb147@github.com>

On Wed, 13 Sep 2023 09:48:00 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

Build changes trivially good.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1643863419

From cstein at openjdk.org  Tue Sep 26 09:58:12 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 26 Sep 2023 09:58:12 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547
In-Reply-To: 
References: 
Message-ID: 

On Tue, 26 Sep 2023 09:40:11 GMT, Matthias Baesken  wrote:

> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.

Instead of adding those directives to all 11 files, can you please try adding `modules = ...` line to the associated `TEST.properties` file? Such as:

modules = jdk.jpackage


https://github.com/openjdk/jdk/blob/52983ed529182901db4e33857bfeab2727e235df/test/jdk/tools/jpackage/junit/TEST.properties#L1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15916#issuecomment-1735213797

From jpai at openjdk.org  Tue Sep 26 09:58:14 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 26 Sep 2023 09:58:14 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547
In-Reply-To: 
References: 
Message-ID: 

On Tue, 26 Sep 2023 09:40:11 GMT, Matthias Baesken  wrote:

> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.

test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @modules jdk.jpackage

Hello Matthias,

Would moving `@modules jdk.jpackage` to `test/jdk/tools/jpackage/junit/TEST.properties` like the following:


modules=jdk.jpackage


and adding the `@test` declaration to these  tests, get this passing on AIX? That way it will avoid the repeated `@modules` declaration in these test files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15916#discussion_r1336954393

From jpai at openjdk.org  Tue Sep 26 10:04:12 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 26 Sep 2023 10:04:12 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 26 Sep 2023 09:53:08 GMT, Jaikiran Pai  wrote:

>> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.
>
> test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @modules jdk.jpackage
> 
> Hello Matthias,
> 
> Would moving `@modules jdk.jpackage` to `test/jdk/tools/jpackage/junit/TEST.properties` like the following:
> 
> 
> modules=jdk.jpackage
> 
> 
> and adding the `@test` declaration to these  tests, get this passing on AIX? That way it will avoid the repeated `@modules` declaration in these test files.

Christian noted that the `@test` in each of the test files may not even be needed if you could just add the `modules=jdk.jpackage` to the existing content of `TEST.properties` file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15916#discussion_r1336964564

From mcimadamore at openjdk.org  Tue Sep 26 10:24:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 26 Sep 2023 10:24:21 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 25 Sep 2023 16:59:30 GMT, Jan Lahoda  wrote:

>> This PR finalizes the feature of unnamed variables and patterns.
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> - [ ] Change requires CSR request [JDK-8315851](https://bugs.openjdk.org/browse/JDK-8315851) to be approved
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649` \
>> `$ git checkout pull/15649`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/15649` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/15649/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 15649`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 15649`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/15649.diff
>> 
>> 

>> 
>> 
>> ### Webrev
>> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/15649#issuecomment-1733906010)
>
> test/langtools/tools/javac/lambda/IdentifierTest9.out line 33:
> 
>> 31: IdentifierTest.java:152:17: compiler.err.use.of.underscore.not.allowed
>> 32: IdentifierTest.java:158:16: compiler.err.use.of.underscore.not.allowed.with.brackets
>> 33: IdentifierTest.java:160:25: compiler.err.use.of.underscore.not.allowed
> 
> Note the errors are like:
> 
> /home/jlahoda/src/jdk/jdk2/test/langtools/tools/javac/lambda/IdentifierTest.java:160: error: as of release 21, the underscore keyword '_' is only allowed to declare
>         for(String _s : _ ) {
>                         ^
>   unnamed patterns, local variables, exception parameters or lambda parameters
> 
> 
> At least the release version should be updated, but to not let the message to be broken into two lines like this. Maybe produce a top-level diagnostic along the line of "underscore not allowed here" with sub-diagnostic with the details (which then can (maybe?) span multiple lines).
> 
> Also, the wording sounds to me like if there was a restriction in JDK 22, while underscore is actually permitted on more places than before.
> 
> So, maybe something like:
> 
> 
> underscore not allowed here
> as of release 9, ''_'' is a keyword, and may not be used as an identifier
> as of release 21, ''_'' can be used as a name in the declaration of unnamed patterns, local variables, exception parameters or lambda parameters
> 
> ?
> Just an idea.

I agree. Also, this is not helped by the fact that in this particular message, the `_` does not appear in a variable declaration. Maybe we should use two distinct messages for when `_` is found as an "expression" (e.g. an identifier) and when it is used as a declaration _name_.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336987040

From mbaesken at openjdk.org  Tue Sep 26 12:15:48 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Sep 2023 12:15:48 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547 [v2]
In-Reply-To: 
References: 
Message-ID: 

> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  move module info to TEST.properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15916/files
  - new: https://git.openjdk.org/jdk/pull/15916/files/c0899205..2e6f1713

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15916&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15916&range=00-01

  Stats: 60 lines in 12 files changed: 1 ins; 58 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15916/head:pull/15916

PR: https://git.openjdk.org/jdk/pull/15916

From mbaesken at openjdk.org  Tue Sep 26 12:20:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Sep 2023 12:20:55 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547 [v3]
In-Reply-To: 
References: 
Message-ID: <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>

> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove added blank lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15916/files
  - new: https://git.openjdk.org/jdk/pull/15916/files/2e6f1713..eca268f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15916&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15916&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15916/head:pull/15916

PR: https://git.openjdk.org/jdk/pull/15916

From mbaesken at openjdk.org  Tue Sep 26 12:20:57 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 26 Sep 2023 12:20:57 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547
In-Reply-To: 
References: 
Message-ID: <6U8pDi1GsQwUDHIF_kdsPsUzvlmlaAiZAo8hxb_5PcE=.4b14ae70-eb0d-42d0-8436-3db3ed5d82b1@github.com>

On Tue, 26 Sep 2023 09:40:11 GMT, Matthias Baesken  wrote:

> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.

Thanks for the hint, adding the module info to TEST.properties works too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15916#issuecomment-1735425349

From asotona at openjdk.org  Tue Sep 26 12:32:37 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Sep 2023 12:32:37 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
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:

  PreviewFeature annotated with JEP 457

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/6594ee74..77631a78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=00-01

  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 avoitylov at openjdk.org  Tue Sep 26 12:38:46 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 26 Sep 2023 12:38:46 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v2]
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  add regression test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15906/files
  - new: https://git.openjdk.org/jdk/pull/15906/files/b95bf8f0..003c142e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=00-01

  Stats: 26 lines in 1 file changed: 19 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15906/head:pull/15906

PR: https://git.openjdk.org/jdk/pull/15906

From jpai at openjdk.org  Tue Sep 26 12:47:13 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 26 Sep 2023 12:47:13 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547 [v3]
In-Reply-To: <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
References: 
 <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
Message-ID: 

On Tue, 26 Sep 2023 12:20:55 GMT, Matthias Baesken  wrote:

>> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove added blank lines

Thank you Matthias for the update and testing the change. The change looks fine to me, but I'll let someone more familiar with these jpackage tests to officially review this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15916#issuecomment-1735472237

From rgiulietti at openjdk.org  Tue Sep 26 13:03:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 26 Sep 2023 13:03:15 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v2]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: 

On Tue, 26 Sep 2023 12:38:46 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add regression test

src/java.base/share/classes/java/lang/String.java line 2159:

> 2157:             return false;
> 2158:         }
> 2159:         // Any strings match if length < 0

Suggestion:

        // Any strings match if len < 0

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15906#discussion_r1337170256

From liach at openjdk.org  Tue Sep 26 13:13:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 26 Sep 2023 13:13:24 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Tue, 26 Sep 2023 12:32:37 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:
> 
>   PreviewFeature annotated with JEP 457

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:

> 80:         STRUCTURED_CONCURRENCY,
> 81:         @JEP(number=457, title="ClassFile API", status="Preview")
> 82:         CLASSFILE_API,

Since `Classfile` gets renamed to `ClassFile`, do we rename the title to `Class-File API` and constant to `CLASS_FILE_API`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1337183618

From asotona at openjdk.org  Tue Sep 26 13:40:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Sep 2023 13:40:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Tue, 26 Sep 2023 13:10:15 GMT, Chen Liang  wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PreviewFeature annotated with JEP 457
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:
> 
>> 80:         STRUCTURED_CONCURRENCY,
>> 81:         @JEP(number=457, title="ClassFile API", status="Preview")
>> 82:         CLASSFILE_API,
> 
> Since `Classfile` gets renamed to `ClassFile`, do we rename the title to `Class-File API` and constant to `CLASS_FILE_API`?

Rename of classes and interfaces from `Classfile` to `ClassFile` is significant for the API.
`ClassFile` and `Class-File` are considered equal in text.
Internal name of the preview feature is temporary and  invisible in the API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1337223631

From cstein at openjdk.org  Tue Sep 26 13:48:14 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 26 Sep 2023 13:48:14 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547 [v3]
In-Reply-To: <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
References: 
 <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
Message-ID: 

On Tue, 26 Sep 2023 12:20:55 GMT, Matthias Baesken  wrote:

>> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove added blank lines

Looks good to me.

-------------

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15916#pullrequestreview-1644317352

From asemenyuk at openjdk.org  Tue Sep 26 13:48:14 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 26 Sep 2023 13:48:14 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547 [v3]
In-Reply-To: <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
References: 
 <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
Message-ID: 

On Tue, 26 Sep 2023 12:20:55 GMT, Matthias Baesken  wrote:

>> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove added blank lines

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15916#pullrequestreview-1644318101

From avoitylov at openjdk.org  Tue Sep 26 14:06:56 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 26 Sep 2023 14:06:56 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v3]
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/String.java
  
  Co-authored-by: Raffaello Giulietti 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15906/files
  - new: https://git.openjdk.org/jdk/pull/15906/files/003c142e..7a505e0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15906/head:pull/15906

PR: https://git.openjdk.org/jdk/pull/15906

From avoitylov at openjdk.org  Tue Sep 26 14:09:17 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 26 Sep 2023 14:09:17 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v2]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: 

On Tue, 26 Sep 2023 12:38:46 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add regression test

@rgiulietti @simonis @AlanBateman thank you for the suggestions! 

test/jdk/java/lang/String/RegionMatches.java was converted to testng and split into two @Tests, the latter now covers 8316879.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1735615353

From rgiulietti at openjdk.org  Tue Sep 26 14:16:26 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 26 Sep 2023 14:16:26 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview)
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: 

On Fri, 8 Sep 2023 14:17:29 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

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 45:

> 43:      *
> 44:      * */
> 45:     public static boolean byte_char(byte n)    {return n == (char) n;}

This method doesn't buy you anything more than `int_char(int)`, so I wonder if it is useful.
(The bytecode instructions are exactly the same.)

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 53:

> 51:      *
> 52:      * */
> 53:     public static boolean short_byte(short n)  {return n == (short)(byte)(n);}

Here, too, I wonder if this method is useful, given that `int_byte(int)` gives the same outcomes and its bytecode is one instruction shorter.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 61:

> 59:      *
> 60:      * */
> 61:     public static boolean short_char(short n)  {return n == (char)(n);}

Similarly, usages can be replaced by `int_char(int)`.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 69:

> 67:      *
> 68:      * */
> 69:     public static boolean char_byte(char n)    {return n == (byte)(n);}

Usages can be replaced by `int_byte(int)`.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 77:

> 75:      *
> 76:      * */
> 77:     public static boolean char_short(char n)   {return n == (short)(n);}

Can be replaced by `int_short(int)`.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 85:

> 83:      *
> 84:      * */
> 85:     public static boolean int_byte(int n)      {return n == (int)(byte)(n);}

Suggestion:

    public static boolean int_byte(int n)      {return n == (int)(byte)n;}

Just for consistency with other methods.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 93:

> 91:      *
> 92:      * */
> 93:     public static boolean int_short(int n)     {return n == (int)(short)(n);}

Suggestion:

    public static boolean int_short(int n)     {return n == (int)(short)n;}

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 101:

> 99:      *
> 100:      * */
> 101:     public static boolean int_char(int n)      {return n == (char)(n);}

Suggestion:

    public static boolean int_char(int n)      {return n == (int)(char)n;}

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 117:

> 115:      *
> 116:      * */
> 117:     public static boolean long_byte(long n)    {return n == (long)(byte)(n);}

Suggestion:

    public static boolean long_byte(long n)    {return n == (long)(byte)n;}

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 125:

> 123:      *
> 124:      * */
> 125:     public static boolean long_short(long n)   {return n == (long)(short)(n);}

Suggestion:

    public static boolean long_short(long n)   {return n == (long)(short)n;}

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 133:

> 131:      *
> 132:      * */
> 133:     public static boolean long_char(long n)    {return n == (char)(n);}

Suggestion:

    public static boolean long_char(long n)    {return n == (long)(char)n;}

for consistency.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 141:

> 139:      *
> 140:      * */
> 141:     public static boolean long_int(long n)     {return n == (long)(int)(n);}

Suggestion:

    public static boolean long_int(long n)     {return n == (long)(int)n;}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337239197
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337251147
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337257370
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337259180
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337221803
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337221156
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337220474
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337219930
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337217930
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337217515
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337216448
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337268643

From raffaello.giulietti at oracle.com  Tue Sep 26 14:26:19 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Tue, 26 Sep 2023 16:26:19 +0200
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v2]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
 
Message-ID: 

Since the tests are now TestNG, I think it would make more sense to use 
TestNG `assertTrue` rather than using explicit `if`s and `throw`s.



On 2023-09-26 16:09, Aleksei Voitylov wrote:
> On Tue, 26 Sep 2023 12:38:46 GMT, Aleksei Voitylov  wrote:
> 
>>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>>>
>>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>>
>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    add regression test
> 
> @rgiulietti @simonis @AlanBateman thank you for the suggestions!
> 
> test/jdk/java/lang/String/RegionMatches.java was converted to testng and split into two @Tests, the latter now covers 8316879.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1735615353

From duke at openjdk.org  Tue Sep 26 14:28:43 2023
From: duke at openjdk.org (Technici4n)
Date: Tue, 26 Sep 2023 14:28:43 GMT
Subject: RFR: 8314986: Module readability resolution is slow with large numbers
 of automatic modules
Message-ID: 

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

-------------

Commit messages:
 - Initial automatic module perf fix

Changes: https://git.openjdk.org/jdk/pull/15926/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15926&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314986
  Stats: 117 lines in 2 files changed: 74 ins; 43 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15926/head:pull/15926

PR: https://git.openjdk.org/jdk/pull/15926

From rriggs at openjdk.org  Tue Sep 26 14:32:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 26 Sep 2023 14:32:15 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v3]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: 

On Tue, 26 Sep 2023 14:06:56 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/String.java
>   
>   Co-authored-by: Raffaello Giulietti 

src/java.base/share/classes/java/lang/String.java line 2162:

> 2160:         if (len < 0) {
> 2161:            return true;
> 2162:         }

Isn't it also true that the regions trivial match if len == 0?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15906#discussion_r1337310557

From abimpoudis at openjdk.org  Tue Sep 26 14:41:00 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 26 Sep 2023 14:41:00 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR finalizes the feature of unnamed variables and patterns.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change requires CSR request [JDK-8315851](https://bugs.openjdk.org/browse/JDK-8315851) to be approved
> 
> 
> 
> ### Reviewing
> 
Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649` \
> `$ git checkout pull/15649`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/15649` \
> `$ git pull https://git.openjdk.org/jdk.git pull/15649/head`
> 
> 

> 
Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 15649`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 15649`
> 
> 

> 
Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/15649.diff
> 
> 

> 
> 
> ### Webrev
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/15649#issuecomment-1733906010)

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review by @lahodaj

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/d334ff29..3becc945

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=00-01

  Stats: 51 lines in 8 files changed: 7 ins; 2 del; 42 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 Sep 26 14:41:04 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 26 Sep 2023 14:41:04 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 25 Sep 2023 17:05:49 GMT, Jan Lahoda  wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review by @lahodaj
>
> test/langtools/tools/javac/diags/examples/UnderscoreInLambdaExpression.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: // options: -Xlint:preview
> 
> `-Xlint:preview` is probably unnecessary here.

If I remove everything, the example does not work. I will leave a `-source 21`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1337320481

From alanb at openjdk.org  Tue Sep 26 15:01:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Sep 2023 15:01:13 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:19:55 GMT, Technici4n  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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15926#issuecomment-1735718603

From liach at openjdk.org  Tue Sep 26 15:01:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 26 Sep 2023 15:01:17 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:19:55 GMT, Technici4n  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

src/java.base/share/classes/java/lang/module/Resolver.java line 1:

> 1: /*

You should update the ending copyright year of this file from 2022 to 2023.

src/java.base/share/classes/java/lang/module/Resolver.java line 621:

> 619: 
> 620:             String name = m1.name();
> 621:             Set m1Reads = entry.getValue();

Why not just this?

m1Reads.addAll(nameToResolved.values());
m1Reads.remove(m1);

src/java.base/share/classes/java/lang/module/Resolver.java line 639:

> 637:                 parent.configurations()
> 638:                         .map(Configuration::modules)
> 639:                         .flatMap(Set::stream)

Can't this and below step be `.forEach(m1Reads::addAll)`?

src/java.base/share/classes/java/lang/module/Resolver.java line 665:

> 663:                 } else {
> 664:                     // parent configuration, already resolved
> 665:                     // TODO: does this allocate a copy of the set every time?

It doesn't. `List.copyOf` and `Set.copyOf` returns the passed immutable collection instance if input is already an immutable collection.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15926#discussion_r1337332185
PR Review Comment: https://git.openjdk.org/jdk/pull/15926#discussion_r1337342558
PR Review Comment: https://git.openjdk.org/jdk/pull/15926#discussion_r1337326631
PR Review Comment: https://git.openjdk.org/jdk/pull/15926#discussion_r1337350597

From duke at openjdk.org  Tue Sep 26 15:53:12 2023
From: duke at openjdk.org (Technici4n)
Date: Tue, 26 Sep 2023 15:53:12 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:19:55 GMT, Technici4n  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

The attached patch helps a lot when there's only automatic modules, but not so much with many non-automatic modules. See for example this updated "test": https://gist.github.com/Technici4n/5ac0744bb85604ed9f81c610151cc884 and the following output:

(numbers not scientific)

[standard jdk 20]
Time for  100 modules = 0.0s
Time for  200 modules = 0.1s
Time for  300 modules = 0.3s
Time for  400 modules = 0.4s
Time for  500 modules = 1.0s
Time for  600 modules = 1.7s
Time for  700 modules = 2.5s
Time for  800 modules = 4.6s
Time for  900 modules = 5.9s
Time for 1000 modules = 6.6s
[with Alan's patch]
Time for  100 modules = 0.0s
Time for  200 modules = 0.0s
Time for  300 modules = 0.1s
Time for  400 modules = 0.2s
Time for  500 modules = 0.3s
Time for  600 modules = 0.5s
Time for  700 modules = 0.9s
Time for  800 modules = 1.5s
Time for  900 modules = 1.9s
Time for 1000 modules = 1.9s

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15926#issuecomment-1735822630

From avoitylov at openjdk.org  Tue Sep 26 16:18:09 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 26 Sep 2023 16:18:09 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v4]
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

Aleksei Voitylov 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/15906/files
  - new: https://git.openjdk.org/jdk/pull/15906/files/7a505e0d..84965be4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15906/head:pull/15906

PR: https://git.openjdk.org/jdk/pull/15906

From avoitylov at openjdk.org  Tue Sep 26 16:18:31 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 26 Sep 2023 16:18:31 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v3]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
 
Message-ID: 

On Tue, 26 Sep 2023 14:29:05 GMT, Roger Riggs  wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/String.java
>>   
>>   Co-authored-by: Raffaello Giulietti 
>
> src/java.base/share/classes/java/lang/String.java line 2162:
> 
>> 2160:         if (len < 0) {
>> 2161:            return true;
>> 2162:         }
> 
> Isn't it also true that the regions trivial match if len == 0?

Yes, you are right. The statement "there is some nonnegative integer k less than len " covers the case len == 0, and the rest of the cases are checked before this line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15906#discussion_r1337471588

From rriggs at openjdk.org  Tue Sep 26 16:27:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 26 Sep 2023 16:27:15 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v4]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: 

On Tue, 26 Sep 2023 16:18:09 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

> test/jdk/java/lang/String/RegionMatches.java was converted to testng and split into two @tests, the latter now covers 8316879.

Can the test use JUnit 5? JUnit is being maintained compared to TestNG.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1735880178

From rriggs at openjdk.org  Tue Sep 26 17:14:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 26 Sep 2023 17:14:56 GMT
Subject: RFR: 8315721: CloseRace.java#id0 fails transiently on libgraal
Message-ID: 

The timing of the test can be disturbed by -Xcomp so do not run with -Xcomp.
The problem appears with the Graal compiler but may also occur on other platforms.

-------------

Commit messages:
 - 8315721: CloseRace.java#id0 fails transiently on libgraal

Changes: https://git.openjdk.org/jdk/pull/15930/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15930&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315721
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15930/head:pull/15930

PR: https://git.openjdk.org/jdk/pull/15930

From lancea at openjdk.org  Tue Sep 26 17:42:11 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 26 Sep 2023 17:42:11 GMT
Subject: RFR: 8315721: CloseRace.java#id0 fails transiently on libgraal
In-Reply-To: 
References: 
Message-ID: 

On Tue, 26 Sep 2023 17:03:00 GMT, Roger Riggs  wrote:

> The timing of the test can be disturbed by -Xcomp so do not run with -Xcomp.
> The problem appears with the Graal compiler but may also occur on other platforms.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15930#pullrequestreview-1644854523

From bpb at openjdk.org  Tue Sep 26 18:03:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 26 Sep 2023 18:03:54 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v7]
In-Reply-To: 
References: 
Message-ID: 

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316000: Modify spec and return verbiage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15673/files
  - new: https://git.openjdk.org/jdk/pull/15673/files/2ec7d229..61cdf016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=05-06

  Stats: 50 lines in 1 file changed: 12 ins; 16 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/15673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15673/head:pull/15673

PR: https://git.openjdk.org/jdk/pull/15673

From rgiulietti at openjdk.org  Tue Sep 26 18:08:13 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 26 Sep 2023 18:08:13 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v4]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
 
Message-ID: 

On Tue, 26 Sep 2023 16:23:58 GMT, Roger Riggs  wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comments
>
>> test/jdk/java/lang/String/RegionMatches.java was converted to testng and split into two @tests, the latter now covers 8316879.
> 
> Can the test use JUnit 5? JUnit is being maintained compared to TestNG.

I second @RogerRiggs' note that JUnit is better maintained than TestNG.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1736032210

From duke at openjdk.org  Tue Sep 26 18:25:12 2023
From: duke at openjdk.org (Logan Abernathy)
Date: Tue, 26 Sep 2023 18:25:12 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547 [v3]
In-Reply-To: <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
References: 
 <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
Message-ID: 

On Tue, 26 Sep 2023 12:20:55 GMT, Matthias Baesken  wrote:

>> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove added blank lines

Marked as reviewed by M4ximumPizza at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15916#pullrequestreview-1644929303

From rriggs at openjdk.org  Tue Sep 26 18:34:14 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 26 Sep 2023 18:34:14 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 14:30:18 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:
> 
>   fix typo

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15768#pullrequestreview-1644943591

From bchristi at openjdk.org  Tue Sep 26 18:39:36 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 26 Sep 2023 18:39:36 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian  wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some more tabs

Your persistence finally paid off, **bridgekeeper** - well played.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8311#issuecomment-1736077085

From psandoz at openjdk.org  Tue Sep 26 18:47:22 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 18:47:22 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: 
References: 
 
Message-ID: <2AguFuRwAmTfpUeFVU2toX7gEtL5VoWKOfkeiHLtpow=.084205ec-e2eb-4dd7-ada2-732b316f6a86@github.com>

On Mon, 25 Sep 2023 16:54:10 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:
> 
>   fix typos

src/java.base/share/classes/java/lang/Module.java line 328:

> 326:                 System.err.printf("""
> 327:                         WARNING: A restricted method in %s has been called
> 328:                         WARNING: %s has been called%s in %s

Suggestion:

                        WARNING: %s has been called by %s in %s

?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337640870

From psandoz at openjdk.org  Tue Sep 26 19:06:24 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 19:06:24 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 25 Sep 2023 16:54:10 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:
> 
>   fix typos

src/java.base/share/classes/java/lang/foreign/Linker.java line 735:

> 733:          *
> 734:          * @apiNote This linker option can not be combined with {@link #critical}.
> 735:          *

That seems more specification (that can be asserted on) then an informative note.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337661700

From almatvee at openjdk.org  Tue Sep 26 19:08:11 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 26 Sep 2023 19:08:11 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547 [v3]
In-Reply-To: <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
References: 
 <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
Message-ID: 

On Tue, 26 Sep 2023 12:20:55 GMT, Matthias Baesken  wrote:

>> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove added blank lines

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15916#pullrequestreview-1645006874

From psandoz at openjdk.org  Tue Sep 26 21:20:23 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 21:20:23 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 25 Sep 2023 16:54:10 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:
> 
>   fix typos

src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 152:

> 150:     private static long allocateMemoryWrapper(long size) {
> 151:         try {
> 152:             return UNSAFE.allocateMemory(size);

Since we now zero memory only when needed we should test very carefully.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337794211

From psandoz at openjdk.org  Tue Sep 26 21:31:23 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 21:31:23 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 25 Sep 2023 16:54:10 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:
> 
>   fix typos

src/java.base/share/classes/java/lang/foreign/Linker.java line 35:

> 33: 
> 34: import java.lang.invoke.MethodHandle;
> 35: import java.nio.ByteOrder;

Unused?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337802958

From naoto at openjdk.org  Tue Sep 26 21:56:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Sep 2023 21:56:26 GMT
Subject: RFR: 8316974: ListFormat creation is unsuccessful for some of the
 supported Locales
Message-ID: 

Some CLDR locales have partial list patterns, such as only the "end" pattern, and expect "start" and "middle" patterns to be inherited from parent locales. Made the code capable of the inheritance.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/15935/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15935&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316974
  Stats: 39 lines in 2 files changed: 35 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15935/head:pull/15935

PR: https://git.openjdk.org/jdk/pull/15935

From psandoz at openjdk.org  Tue Sep 26 22:02:20 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 22:02:20 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 25 Sep 2023 16:54:10 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:
> 
>   fix typos

This looks good.

In the implementation the functional interfaces `BindingInterpreter.StoreFunc/LoadFunc` are package private, but are used in internal public signatures. This was previously like this and it's not a big deal but i recommend making those interfaces public.

We can also remove `@enablePreview` from `IndirectVarHandleTest`

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1645266436

From naoto at openjdk.org  Tue Sep 26 22:27:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Sep 2023 22:27:55 GMT
Subject: RFR: 8316974: ListFormat creation is unsuccessful for some of the
 supported Locales [v2]
In-Reply-To: 
References: 
Message-ID: 

> Some CLDR locales have partial list patterns, such as only the "end" pattern, and expect "start" and "middle" patterns to be inherited from parent locales. Made the code capable of the inheritance.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fixed cache

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15935/files
  - new: https://git.openjdk.org/jdk/pull/15935/files/af695c6e..623d029f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15935&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15935&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15935/head:pull/15935

PR: https://git.openjdk.org/jdk/pull/15935

From jlu at openjdk.org  Tue Sep 26 22:48:18 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Sep 2023 22:48:18 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
> 
> Any files named BugXXXXXXX.java will be renamed after review.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  rename files from bugXXXXXXX to something more descriptive

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15853/files
  - new: https://git.openjdk.org/jdk/pull/15853/files/db54d231..a65b3098

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=03-04

  Stats: 18 lines in 9 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/15853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15853/head:pull/15853

PR: https://git.openjdk.org/jdk/pull/15853

From dl at openjdk.org  Tue Sep 26 22:57:07 2023
From: dl at openjdk.org (Doug Lea)
Date: Tue, 26 Sep 2023 22:57:07 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v39]
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 conservative resize checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/8e6b0be1..038d5874

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=37-38

  Stats: 16 lines in 1 file changed: 2 ins; 8 del; 6 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 jvernee at openjdk.org  Wed Sep 27 00:26:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 00:26:21 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 26 Sep 2023 21:28:43 GMT, Paul Sandoz  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typos
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 35:
> 
>> 33: 
>> 34: import java.lang.invoke.MethodHandle;
>> 35: import java.nio.ByteOrder;
> 
> Unused?

Yes, I'll remove it.

> src/java.base/share/classes/java/lang/foreign/Linker.java line 735:
> 
>> 733:          *
>> 734:          * @apiNote This linker option can not be combined with {@link #critical}.
>> 735:          *
> 
> That seems more specification (that can be asserted on) then an informative note.

True. I'll fold it into the main spec body.

> src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 152:
> 
>> 150:     private static long allocateMemoryWrapper(long size) {
>> 151:         try {
>> 152:             return UNSAFE.allocateMemory(size);
> 
> Since we now zero memory only when needed we should test very carefully.

Yes. The `makeNativeSegment` is currently only called from ArenaImpl, which is also responsible for zeroing the memory.

I'll rename `makeNativeSegment` to `makeNativeSegmentNoZeroing` to make it extra clear for callers that memory will not be zeroed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337898179
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337898017
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337899265

From jvernee at openjdk.org  Wed Sep 27 00:33:37 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 00:33:37 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <2AguFuRwAmTfpUeFVU2toX7gEtL5VoWKOfkeiHLtpow=.084205ec-e2eb-4dd7-ada2-732b316f6a86@github.com>
References: 
 
 <2AguFuRwAmTfpUeFVU2toX7gEtL5VoWKOfkeiHLtpow=.084205ec-e2eb-4dd7-ada2-732b316f6a86@github.com>
Message-ID: 

On Tue, 26 Sep 2023 18:44:01 GMT, Paul Sandoz  wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typos
>
> src/java.base/share/classes/java/lang/Module.java line 328:
> 
>> 326:                 System.err.printf("""
>> 327:                         WARNING: A restricted method in %s has been called
>> 328:                         WARNING: %s has been called%s in %s
> 
> Suggestion:
> 
>                         WARNING: %s has been called by %s in %s
> 
> ?

The current code does the right thing, since in some cases the caller is `null` and the second `%s` should expand to an empty string. So  in the `caller == null` case, the message becomes:

    Class::method has been called in an unnamed module

There was also an offline suggestion to change it to:

    Class::method has been called by code in an unnamed module
    
Which I think is a good idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337902449

From jvernee at openjdk.org  Wed Sep 27 00:36:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 00:36:22 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 26 Sep 2023 21:59:35 GMT, Paul Sandoz  wrote:

> In the implementation the functional interfaces `BindingInterpreter.StoreFunc/LoadFunc` are package private, but are used in internal public signatures. This was previously like this and it's not a big deal but i recommend making those interfaces public.

This was fixed in the panama-foreign repo: https://github.com/openjdk/panama-foreign/pull/891

I'll add that commit to this patch as well.

> We can also remove `@enablePreview` from `IndirectVarHandleTest`

Good catch!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1736481584

From jvernee at openjdk.org  Wed Sep 27 00:53:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 00:53:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: 
References: 
Message-ID: <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@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 two additional commits since the last revision:

 - Fix visibility issues
   
   Reviewed-by: mcimadamore
 - Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/0244845a..f6ab4dc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=26-27

  Stats: 11 lines in 6 files changed: 0 ins; 3 del; 8 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 joehw at openjdk.org  Wed Sep 27 03:35:10 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 27 Sep 2023 03:35:10 GMT
Subject: RFR: 8316974: ListFormat creation is unsuccessful for some of the
 supported Locales [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 26 Sep 2023 22:27:55 GMT, Naoto Sato  wrote:

>> Some CLDR locales have partial list patterns, such as only the "end" pattern, and expect "start" and "middle" patterns to be inherited from parent locales. Made the code capable of the inheritance.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed cache

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15935#pullrequestreview-1645531435

From duke at openjdk.org  Wed Sep 27 03:54:12 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 27 Sep 2023 03:54:12 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 14:30:18 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:
> 
>   fix typo

HexFormat.DIGITS now uses 256-length byte[], which can be changed to 128-length. This is a small change. Should it be changed in the current PR?


public final class HexFormat {
    private static final byte[] DIGITS = {
            -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, 10, 11, 12, 13, 14, 15, -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, 10, 11, 12, 13, 14, 15, -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
           // remove 128 - 255
    };

    public static boolean isHexDigit(int ch) {
        // unsigned right shift 8 change to 7
        return ((ch >>> 7) == 0 && DIGITS[ch] >= 0);
    }

    public static int fromHexDigit(int ch) {
        int value;
        // unsigned right shift 8 change to 7
        if ((ch >>> 7) == 0 && (value = DIGITS[ch]) >= 0) 
        ...
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1736630070

From rriggs at openjdk.org  Wed Sep 27 04:19:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Sep 2023 04:19:15 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 19 Sep 2023 14:30:18 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:
> 
>   fix typo

ok, but perhaps you can shrink it further, if it does not hurt performance, by subtracting 0x20 before indexing and cut the table to 64 bytes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1736644966

From duke at openjdk.org  Wed Sep 27 06:18:45 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Wed, 27 Sep 2023 06:18:45 GMT
Subject: RFR: 8316998: Remove redundant type arguments
Message-ID: 

Remove cases of redundant type arguments in the java.util.stream package.

-------------

Commit messages:
 - Remove redundant type arguments.

Changes: https://git.openjdk.org/jdk/pull/15936/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15936&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316998
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15936/head:pull/15936

PR: https://git.openjdk.org/jdk/pull/15936

From mbaesken at openjdk.org  Wed Sep 27 06:47:22 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 27 Sep 2023 06:47:22 GMT
Subject: RFR: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547 [v3]
In-Reply-To: <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
References: 
 <1ZHgyQsCOOWHvh_gFSiFtDvIuC9h7BJorZHcVKeLTkA=.daaa090d-a610-4a5c-b668-c1d5d9be48c0@github.com>
Message-ID: 

On Tue, 26 Sep 2023 12:20:55 GMT, Matthias Baesken  wrote:

>> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove added blank lines

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15916#issuecomment-1736794264

From mbaesken at openjdk.org  Wed Sep 27 06:47:24 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 27 Sep 2023 06:47:24 GMT
Subject: Integrated: JDK-8316897: tools/jpackage/junit tests fail on AIX after
 JDK-8316547
In-Reply-To: 
References: 
Message-ID: <36UiCWesZIvRRZ2kI8WIzTC91HkQeE3liEr2YOcT97I=.233a7e45-f3c4-43ba-9d24-2d02ec676ba6@github.com>

On Tue, 26 Sep 2023 09:40:11 GMT, Matthias Baesken  wrote:

> AIX currently does not have the jdk.jpackage system module. We have to take this into account for these jpackage tests.

This pull request has now been integrated.

Changeset: b659e034
Author:    Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/b659e0343a3273867560e75a38b12e6223b301e7
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8316897: tools/jpackage/junit tests fail on AIX after JDK-8316547

Reviewed-by: cstein, asemenyuk, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/15916

From jpai at openjdk.org  Wed Sep 27 07:20:18 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 27 Sep 2023 07:20:18 GMT
Subject: RFR: 8316946: jtreg failure handler pages are mislabelling the
 jcmd/thread/dump_to_file results.
Message-ID: 

Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8316946?

Failure handler actions can specify a "successArtifacts" property value, which are file name(s) for which hypherlinks will be created in the "processes.html" file. This property value can contain replacable placeholder tokens like "%p" (process id) "%iterCount" (iteration count, if the action's command is repeated).

The issue here was caused by a bug in the handling of the "successArtifacts" value. If there were more than one process for which we were running the action (of collecting thread dumps), then the original (raw) value of "successArtifacts" property wasn't being held on to. As a result, for the second process for which the hyperlink was being created, an incorrect link would be generated.

The commit here retains the raw value of "successArtifacts" property in the `PatternAction` (just like we do for "args" property) so that it can be used to repeatedly replace the placeholders, each time the action is run for a different process.

I've run this change against our internal CI to verify it doesn't cause any regressions. tier1, tier2 and tier3 was run successfully. Additionally, I have run a couple of jtreg test cases which intentionally timeout, so that I can verify that the generated "processes.html" now contains the correct hyperlinks to the thread dump files for each process.

-------------

Commit messages:
 - 8316946: jtreg failure handler pages are mislabelling the jcmd/thread/dump_to_file results.

Changes: https://git.openjdk.org/jdk/pull/15939/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15939&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316946
  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15939/head:pull/15939

PR: https://git.openjdk.org/jdk/pull/15939

From duke at openjdk.org  Wed Sep 27 07:42:16 2023
From: duke at openjdk.org (Technici4n)
Date: Wed, 27 Sep 2023 07:42:16 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:54:37 GMT, Chen Liang  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
>
> src/java.base/share/classes/java/lang/module/Resolver.java line 665:
> 
>> 663:                 } else {
>> 664:                     // parent configuration, already resolved
>> 665:                     // TODO: does this allocate a copy of the set every time?
> 
> It doesn't. `List.copyOf` and `Set.copyOf` returns the passed immutable collection instance if input is already an immutable collection.

The input did not seem immutable however

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15926#discussion_r1338177073

From alanb at openjdk.org  Wed Sep 27 07:54:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 07:54:50 GMT
Subject: RFR: 8316924: java/lang/Thread/virtual/stress/ParkALot.java times out
Message-ID: 

A test only change to a stress test for virtual thread parking/unparking to limit execution time on a larger systems. Right run, the test bashes parking/unparking for 1, 2, 3, ... up to the number of half the hardware threads. It is changed to limit it to 4 iterations. It is also dialed down for debug builds as they may run with -XX:+VerifyContinuations which is an expensive assert (but an important one for tests like that).

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15940/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15940&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316924
  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15940/head:pull/15940

PR: https://git.openjdk.org/jdk/pull/15940

From alanb at openjdk.org  Wed Sep 27 08:06:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 08:06:13 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 26 Sep 2023 18:03:54 GMT, Brian Burkhalter  wrote:

>> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316000: Modify spec and return verbiage

src/java.base/share/classes/java/io/File.java line 1630:

> 1628:      * method does nothing and returns the value of the {@code readable}
> 1629:      * parameter.
> 1630:      *

I think we are close to find the right wording for this. The return description looks fine. For the method description, I have two suggested changes:

1.  "If setting the read permission is supported" -> "If the platform supports settings a file's read permission".

2. "If the platform or underlying  file system does not support" -> "If the platform does not support". The reason for this is that the underlying file systems may or may support file permissions, an implementation can't distinguish those.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15673#discussion_r1338208315

From duke at openjdk.org  Wed Sep 27 08:56:48 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Wed, 27 Sep 2023 08:56:48 GMT
Subject: RFR: 8317034: Redundant type cast
Message-ID: 

Remove redundant type cast in the java.util.stream package.

-------------

Commit messages:
 - Remove redundant type cast.

Changes: https://git.openjdk.org/jdk/pull/15942/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317034
  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15942/head:pull/15942

PR: https://git.openjdk.org/jdk/pull/15942

From aturbanov at openjdk.org  Wed Sep 27 09:07:19 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 27 Sep 2023 09:07:19 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v10]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Mon, 25 Sep 2023 14:28:56 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:
> 
>   refactor for review & remove comment

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 duke at openjdk.org  Wed Sep 27 09:07:44 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 27 Sep 2023 09:07:44 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v8]
In-Reply-To: 
References: 
Message-ID: <9YOY2Anr1ITSCkpsfGt9UjMcceBvjYuFJhfC-lx-LuM=.64e11edb-b412-4385-bf75-604f155c7a1a@github.com>

> 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:

  reduce the size of HexFormat##DIGITS, from 256 to 128

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15768/files
  - new: https://git.openjdk.org/jdk/pull/15768/files/8eff0ee4..2ed9ac37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=06-07

  Stats: 11 lines in 1 file changed: 0 ins; 8 del; 3 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 duke at openjdk.org  Wed Sep 27 09:08:07 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 27 Sep 2023 09:08:07 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 27 Sep 2023 04:16:11 GMT, Roger Riggs  wrote:

> ok, but perhaps you can shrink it further, if it does not hurt performance, by subtracting 0x20 before indexing and cut the table to 64 bytes.

If you use DIGITS of size 54, performance will be 10% slower,  The code is written like this: 


public final class HexFormat {
    private static final byte[] DIGITS = {
             0,  1,  2,  3,  4,  5,  6,  7,  8,  9, -1, -1, -1, -1, -1, -1,
            -1, 10, 11, 12, 13, 14, 15, -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, 10, 11, 12, 13, 14, 15
           // remove 128 - 255
    };

    public static boolean isHexDigit(int ch) {
        // unsigned right shift 8 change to 7
        return (ch >= '0' && ch <= 'f' && DIGITS[ch - '0'] >= 0);
    }

    public static int fromHexDigit(int ch) {
        int value;
        // unsigned right shift 8 change to 7
        if (ch >= '0' && ch <= 'f' && (value = DIGITS[ch - '0']) >= 0) 
        ...
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1737001849

From aturbanov at openjdk.org  Wed Sep 27 09:25:11 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 27 Sep 2023 09:25:11 GMT
Subject: RFR: 8316144: Remove unused field
 jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element._Depth
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 14 Sep 2023 21:30:39 GMT, Lance Andersen  wrote:

>Joe is on holiday so please wait for his input as there are some additional constants that may also be removed.

BTW, Who is Joe? 
?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15692#issuecomment-1737031055

From duke at openjdk.org  Wed Sep 27 09:35:47 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 27 Sep 2023 09:35:47 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v11]
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:

  code format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/ba4660a1..eafac656

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=09-10

  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 duke at openjdk.org  Wed Sep 27 09:41:14 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 27 Sep 2023 09:41:14 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v11]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: <4iN4ROrBJbtf7HhuxP9_guULr7D3Pl344dVOPvgDpNY=.8aa82f8c-b7a8-4f3d-951d-7f1f1c1f9cbe@github.com>

On Wed, 27 Sep 2023 09:35:47 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:
> 
>   code format

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 vklang at openjdk.org  Wed Sep 27 09:51:11 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 27 Sep 2023 09:51:11 GMT
Subject: RFR: 8316924: java/lang/Thread/virtual/stress/ParkALot.java times
 out
In-Reply-To: 
References: 
Message-ID: <33WwVG3WbqoAcg-DPMuCKPDHnc9BZMvMARQQs_ZYKJI=.18e857b7-a68d-473b-b595-d5058090b2d6@github.com>

On Wed, 27 Sep 2023 07:47:19 GMT, Alan Bateman  wrote:

> A test only change to a stress test for virtual thread parking/unparking to limit execution time on a larger systems. Right run, the test bashes parking/unparking for 1, 2, 3, ... up to the number of half the hardware threads. It is changed to limit it to 4 iterations. It is also dialed down for debug builds as they may run with -XX:+VerifyContinuations which is an expensive assert (but an important one for tests like that).

test/jdk/java/lang/Thread/virtual/stress/ParkALot.java line 91:

> 89:                 LockSupport.unpark(vthread);
> 90:             } else {
> 91:                 Thread.yield();

?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15940#discussion_r1338355392

From avoitylov at openjdk.org  Wed Sep 27 09:58:58 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Wed, 27 Sep 2023 09:58:58 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v5]
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

Aleksei Voitylov 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/15906/files
  - new: https://git.openjdk.org/jdk/pull/15906/files/84965be4..caaa99db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=03-04

  Stats: 9 lines in 1 file changed: 1 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15906/head:pull/15906

PR: https://git.openjdk.org/jdk/pull/15906

From rgiulietti at openjdk.org  Wed Sep 27 10:40:13 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 27 Sep 2023 10:40:13 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v5]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: 

On Wed, 27 Sep 2023 09:58:58 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Marked as reviewed by rgiulietti (Committer).

LGTM (but I'm not an official Reviewer)

-------------

PR Review: https://git.openjdk.org/jdk/pull/15906#pullrequestreview-1646155823
PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1737140274

From jpai at openjdk.org  Wed Sep 27 11:26:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 27 Sep 2023 11:26:11 GMT
Subject: RFR: 8316924: java/lang/Thread/virtual/stress/ParkALot.java times
 out
In-Reply-To: 
References: 
Message-ID: <6f-xtzV3eA-hPjn3WakGZkMno-pJrkeJkAykUNK1Qt4=.7a750336-1936-4b92-a2ba-608ecdcddd6f@github.com>

On Wed, 27 Sep 2023 07:47:19 GMT, Alan Bateman  wrote:

> A test only change to a stress test for virtual thread parking/unparking to limit execution time on a larger systems. Right run, the test bashes parking/unparking for 1, 2, 3, ... up to the number of half the hardware threads. It is changed to limit it to 4 iterations. It is also dialed down for debug builds as they may run with -XX:+VerifyContinuations which is an expensive assert (but an important one for tests like that).

The change looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15940#pullrequestreview-1646229941

From jpai at openjdk.org  Wed Sep 27 11:38:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 27 Sep 2023 11:38:11 GMT
Subject: RFR: 8315721: CloseRace.java#id0 fails transiently on libgraal
In-Reply-To: 
References: 
Message-ID: 

On Tue, 26 Sep 2023 17:03:00 GMT, Roger Riggs  wrote:

> The timing of the test can be disturbed by -Xcomp so do not run with -Xcomp.
> The problem appears with the Graal compiler but may also occur on other platforms.

The change looks good to me, given the description in the JBS.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15930#pullrequestreview-1646249822

From rgiulietti at openjdk.org  Wed Sep 27 12:36:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 27 Sep 2023 12:36:15 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v5]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: 

On Wed, 27 Sep 2023 09:58:58 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Just out of curiosity: why not write, e.g.,

private final String s1_UTF16 = "\u043d\u0430\u0436\u0434";
private final String s2_UTF16 = "\u0432\u0020\u0441\u0442";

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1737303082

From rgiulietti at openjdk.org  Wed Sep 27 12:47:16 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 27 Sep 2023 12:47:16 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
In-Reply-To: <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.a4abcb81-f3fb-4e40-8079-7862dd47e16d@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
 <8BVBi-R2HrSUTxkD9FI03wPKm0-22HeSX0xadLZoIi4=.d0021a5c-3c4d-4f93-84a8-88a13ebb8e7e@github.com>
 
 <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.a4abcb81-f3fb-4e40-8079-7862dd47e16d@github.com>
Message-ID: <5kUK7lSfT934hQKZsqlY1mMJFhP6M0rBniu3h_X8i2A=.c09d457a-830a-47e1-a767-170c1b87f0d5@github.com>

On Mon, 25 Sep 2023 12:20:36 GMT, ???  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 avoitylov at openjdk.org  Wed Sep 27 12:52:15 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Wed, 27 Sep 2023 12:52:15 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v5]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: <4klIlVjrADW8_PI7cmvPAJF66dLJiL3jGo15JEVbHSk=.022d4870-624f-4b9a-b6fb-44c3c1f2d85f@github.com>

On Wed, 27 Sep 2023 09:58:58 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

\u0XXX\u0XXX\u0XXX just seems harder to read, but maybe it's just me. I don't have a strong opinion on this, let me know if you believe what you suggest somehow improves readability or is more standard.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1737333440

From dl at openjdk.org  Wed Sep 27 12:53:14 2023
From: dl at openjdk.org (Doug Lea)
Date: Wed, 27 Sep 2023 12:53:14 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v40]
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:

  Possibly re-interrupt when stopping

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/038d5874..ed3b7493

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=38-39

  Stats: 27 lines in 1 file changed: 9 ins; 1 del; 17 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 alanb at openjdk.org  Wed Sep 27 12:57:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 12:57:21 GMT
Subject: Integrated: 8316924: java/lang/Thread/virtual/stress/ParkALot.java
 times out
In-Reply-To: 
References: 
Message-ID: <3qPFaRal18gKO1KFMNy4l19sFO5gQIZLmRhnhiqWUbY=.23c44e8d-de58-4795-be0a-8f8f8e1a44b7@github.com>

On Wed, 27 Sep 2023 07:47:19 GMT, Alan Bateman  wrote:

> A test only change to a stress test for virtual thread parking/unparking to limit execution time on a larger systems. Right run, the test bashes parking/unparking for 1, 2, 3, ... up to the number of half the hardware threads. It is changed to limit it to 4 iterations. It is also dialed down for debug builds as they may run with -XX:+VerifyContinuations which is an expensive assert (but an important one for tests like that).

This pull request has now been integrated.

Changeset: b24ad7cf
Author:    Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/b24ad7cf5710c698f5946e10d44785f24431f966
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8316924: java/lang/Thread/virtual/stress/ParkALot.java times out

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/15940

From rgiulietti at openjdk.org  Wed Sep 27 13:09:14 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 27 Sep 2023 13:09:14 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v5]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: <72I-dbQsKfNGE8gTpRjpo0vhaXO2Qo2kFyR6H8yT0I0=.f4585311-c05e-4000-b67c-9f0237ce87bc@github.com>

On Wed, 27 Sep 2023 09:58:58 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

It avoids the two `String` constructor invocations, otherwise it is as (badly) readable as with the `byte[]`.
My question was just curiosity.

The best thing would be to use `"????"` and `"? ??"`, but AFAIK that's not allowed in OpenJDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1737365014

From rriggs at openjdk.org  Wed Sep 27 13:30:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Sep 2023 13:30:30 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v5]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: 

On Wed, 27 Sep 2023 09:58:58 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Changes requested by rriggs (Reviewer).

test/jdk/java/lang/String/RegionMatches.java line 41:

> 39: 
> 40:   private final byte[] b1_UTF16 = new byte[]{0x04, 0x3d, 0x04, 0x30, 0x04, 0x36, 0x04, 0x34};
> 41:   private final byte[] b2_UTF16 = new byte[]{0x04, 0x32, 0x00, 0x20, 0x04, 0x41, 0x04, 0x42};

For strings, the \uxxxx version would be preferred; it is clearer that what the character is and there is less of a chance that the UTF encoding has a mistake.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15906#pullrequestreview-1646531054
PR Review Comment: https://git.openjdk.org/jdk/pull/15906#discussion_r1338610081

From rriggs at openjdk.org  Wed Sep 27 13:33:26 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Sep 2023 13:33:26 GMT
Subject: Integrated: 8315721: CloseRace.java#id0 fails transiently on libgraal
In-Reply-To: 
References: 
Message-ID: <1P39Ve7QP07SH6663Xw4KrvIRbvjWcp3mqHjDRLyVVQ=.60486f61-18f9-45e1-8397-b7d594d9ae41@github.com>

On Tue, 26 Sep 2023 17:03:00 GMT, Roger Riggs  wrote:

> The timing of the test can be disturbed by -Xcomp so do not run with -Xcomp.
> The problem appears with the Graal compiler but may also occur on other platforms.

This pull request has now been integrated.

Changeset: 1be35573
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/1be355734da94243e29f0899b53aa1ebdf3bcb79
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8315721: CloseRace.java#id0 fails transiently on libgraal

Reviewed-by: lancea, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/15930

From duke at openjdk.org  Wed Sep 27 13:35:24 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 27 Sep 2023 13:35:24 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v7]
In-Reply-To: <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.a4abcb81-f3fb-4e40-8079-7862dd47e16d@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
 <8BVBi-R2HrSUTxkD9FI03wPKm0-22HeSX0xadLZoIi4=.d0021a5c-3c4d-4f93-84a8-88a13ebb8e7e@github.com>
 
 <78dMzfY564yxpZEqVxxI_z9-hh7gKhXEykHdSFp_2U8=.a4abcb81-f3fb-4e40-8079-7862dd47e16d@github.com>
Message-ID: <4oceB4d7SqgewxlyuxQohj4zI3VmdJQ6EbV2DfbDeAk=.51242397-9307-47bc-a186-c2a030730364@github.com>

On Mon, 25 Sep 2023 12:20:36 GMT, ???  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 rriggs at openjdk.org  Wed Sep 27 13:39:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Sep 2023 13:39:15 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v8]
In-Reply-To: <9YOY2Anr1ITSCkpsfGt9UjMcceBvjYuFJhfC-lx-LuM=.64e11edb-b412-4385-bf75-604f155c7a1a@github.com>
References: 
 <9YOY2Anr1ITSCkpsfGt9UjMcceBvjYuFJhfC-lx-LuM=.64e11edb-b412-4385-bf75-604f155c7a1a@github.com>
Message-ID: 

On Wed, 27 Sep 2023 09:07:44 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:
> 
>   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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15768#issuecomment-1737413165

From avoitylov at openjdk.org  Wed Sep 27 14:13:05 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Wed, 27 Sep 2023 14:13:05 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v6]
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

Aleksei Voitylov 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/15906/files
  - new: https://git.openjdk.org/jdk/pull/15906/files/caaa99db..aa5faeac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15906&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15906/head:pull/15906

PR: https://git.openjdk.org/jdk/pull/15906

From avoitylov at openjdk.org  Wed Sep 27 14:13:09 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Wed, 27 Sep 2023 14:13:09 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v5]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
 
Message-ID: <-DU3DKqD8Od4gt5ABa726M25DpZW3y_WIjQMr_2ByPw=.a7a4a2b0-caf1-4b79-8287-4c9116fffb6d@github.com>

On Wed, 27 Sep 2023 13:27:10 GMT, Roger Riggs  wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comments
>
> test/jdk/java/lang/String/RegionMatches.java line 41:
> 
>> 39: 
>> 40:   private final byte[] b1_UTF16 = new byte[]{0x04, 0x3d, 0x04, 0x30, 0x04, 0x36, 0x04, 0x34};
>> 41:   private final byte[] b2_UTF16 = new byte[]{0x04, 0x32, 0x00, 0x20, 0x04, 0x41, 0x04, 0x42};
> 
> For strings, the \uxxxx version would be preferred; it is clearer that what the character is and there is less of a chance that the UTF encoding has a mistake.

Done!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15906#discussion_r1338669536

From rriggs at openjdk.org  Wed Sep 27 14:38:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Sep 2023 14:38:18 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v6]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: <1bWgwjFuNBwTMScPdC5yTRm67klPZk1A2UEXjhFV_h0=.af30fd56-6862-4ef4-a194-280f940d1b37@github.com>

On Wed, 27 Sep 2023 14:13:05 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Looks good.  Thanks for the junit and unicode encoding changes.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15906#pullrequestreview-1646792444

From rriggs at openjdk.org  Wed Sep 27 14:41:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Sep 2023 14:41:15 GMT
Subject: RFR: 8316974: ListFormat creation is unsuccessful for some of the
 supported Locales [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 26 Sep 2023 22:27:55 GMT, Naoto Sato  wrote:

>> Some CLDR locales have partial list patterns, such as only the "end" pattern, and expect "start" and "middle" patterns to be inherited from parent locales. Made the code capable of the inheritance.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed cache

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15935#pullrequestreview-1646805858

From alanb at openjdk.org  Wed Sep 27 14:56:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 14:56:29 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
References: 
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
Message-ID: <34zxg0Er5UaZKlmKxpvQ0QxAv8CeXEp0pSemqPgKquo=.165c5ccd-2873-42e7-aefa-e9ba2e78f661@github.com>

On Wed, 27 Sep 2023 00:53:25 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 two additional commits since the last revision:
> 
>  - Fix visibility issues
>    
>    Reviewed-by: mcimadamore
>  - Review comments

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 640:

> 638:                 if (!enableNativeAccess.equals("ALL-UNNAMED")) {
> 639:                     throw new IllegalArgumentException("Only ALL-UNNAMED allowed as value for " + ENABLE_NATIVE_ACCESS);
> 640:                 }

I don't think throwing IAE is right here. It should call abort with a key for the error message. The value of enableNativeAccess can be used as the parameter for the message.

test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckHoistingScaledIV.java line 32:

> 30:  * @modules jdk.incubator.vector
> 31:  * @compile -source ${jdk.version} TestRangeCheckHoistingScaledIV.java
> 32:  * @run main/othervm compiler.rangechecks.TestRangeCheckHoistingScaledIV

Not important but I assume the @compile line can be removed from a number of tests as it's no longer needed. It was needed for tests that didn't use @enablePreview.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338733430
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338737145

From jvernee at openjdk.org  Wed Sep 27 14:56:31 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 14:56:31 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <34zxg0Er5UaZKlmKxpvQ0QxAv8CeXEp0pSemqPgKquo=.165c5ccd-2873-42e7-aefa-e9ba2e78f661@github.com>
References: 
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
 <34zxg0Er5UaZKlmKxpvQ0QxAv8CeXEp0pSemqPgKquo=.165c5ccd-2873-42e7-aefa-e9ba2e78f661@github.com>
Message-ID: 

On Wed, 27 Sep 2023 14:50:32 GMT, Alan Bateman  wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix visibility issues
>>    
>>    Reviewed-by: mcimadamore
>>  - Review comments
>
> test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckHoistingScaledIV.java line 32:
> 
>> 30:  * @modules jdk.incubator.vector
>> 31:  * @compile -source ${jdk.version} TestRangeCheckHoistingScaledIV.java
>> 32:  * @run main/othervm compiler.rangechecks.TestRangeCheckHoistingScaledIV
> 
> Not important but I assume the @compile line can be removed from a number of tests as it's no longer needed. It was needed for tests that didn't use @enablePreview.

Ok, I'll go over all the tests that I've changed and see if there are `@compile` tags that can be removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338741350

From alanb at openjdk.org  Wed Sep 27 15:07:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 15:07:31 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
References: 
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
Message-ID: 

On Wed, 27 Sep 2023 00:53:25 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 two additional commits since the last revision:
> 
>  - Fix visibility issues
>    
>    Reviewed-by: mcimadamore
>  - Review comments

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1103:

> 1101:      * @throws WrongThreadException          if this method is called from a thread {@code T},
> 1102:      *                                       such that {@code isAccessibleBy(T) == false}.
> 1103:      * @throws UnsupportedOperationException if {@code charset} is not a {@linkplain StandardCharsets standard charset}.

The caller can fix/avoid the exception by providing another value for the argument so I think IAE is the unchecked exception for this case rather than UOE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338758920

From jvernee at openjdk.org  Wed Sep 27 16:15:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 16:15:30 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: 
References: 
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
 
Message-ID: 

On Wed, 27 Sep 2023 15:04:12 GMT, Alan Bateman  wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix visibility issues
>>    
>>    Reviewed-by: mcimadamore
>>  - Review comments
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1103:
> 
>> 1101:      * @throws WrongThreadException          if this method is called from a thread {@code T},
>> 1102:      *                                       such that {@code isAccessibleBy(T) == false}.
>> 1103:      * @throws UnsupportedOperationException if {@code charset} is not a {@linkplain StandardCharsets standard charset}.
> 
> The caller can fix/avoid the exception by providing another value for the argument so I think IAE is the unchecked exception for this case rather than UOE.

I agree. I'll make the change for the following `CharSet` accepting methods: `MemorySegment::getString(long,Charset)`, `MemorySegment::setString(long,String,Charset)`, and `SegmentAllocator::allocateFrom(String,Charset)`. (Which should be all of them).

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 640:
> 
>> 638:                 if (!enableNativeAccess.equals("ALL-UNNAMED")) {
>> 639:                     throw new IllegalArgumentException("Only ALL-UNNAMED allowed as value for " + ENABLE_NATIVE_ACCESS);
>> 640:                 }
> 
> I don't think throwing IAE is right here. It should call abort with a key for the error message. The value of enableNativeAccess can be used as the parameter for the message.

Thanks for the suggestion! I'll switch this to using `abort` instead.

Side note: I don't believe I have to add all the different error message translations right? Only the English version?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338855648
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338857229

From mcimadamore at openjdk.org  Wed Sep 27 16:16:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 27 Sep 2023 16:16:43 GMT
Subject: RFR: 8316970: Add internal annotation to mark restricted methods
Message-ID: 

This patch adds a new internal annotation that is used to mark all restricted me
thods in the FFM API. The new annotation is similar to the one we used for preview API methods.

We plan to use the new annotation for adding new javac warnings when calling restricted methods, as well as to add better javadoc support for restricted methods.

I have added a test which, similar to the test for `@CallerSensitive` checks all methods in `java.base` that are annotated with `@Restricted` and makes sure they conform to the list of restricted methods.

-------------

Commit messages:
 - Add restricted method test
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/15947/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15947&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316970
  Stats: 222 lines in 7 files changed: 222 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15947.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15947/head:pull/15947

PR: https://git.openjdk.org/jdk/pull/15947

From bpb at openjdk.org  Wed Sep 27 16:19:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 27 Sep 2023 16:19:04 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v8]
In-Reply-To: 
References: 
Message-ID: 

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316000: Address comment https://github.com/openjdk/jdk/pull/15673#discussion_r1338208315

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15673/files
  - new: https://git.openjdk.org/jdk/pull/15673/files/61cdf016..5dabb216

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15673&range=06-07

  Stats: 24 lines in 1 file changed: 0 ins; 4 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/15673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15673/head:pull/15673

PR: https://git.openjdk.org/jdk/pull/15673

From bpb at openjdk.org  Wed Sep 27 16:19:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 27 Sep 2023 16:19:10 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 27 Sep 2023 08:03:38 GMT, Alan Bateman  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316000: Modify spec and return verbiage
>
> src/java.base/share/classes/java/io/File.java line 1630:
> 
>> 1628:      * method does nothing and returns the value of the {@code readable}
>> 1629:      * parameter.
>> 1630:      *
> 
> I think we are really close to the final wording for this. The return description looks fine. For the method description, I have two suggested changes:
> 
> 1.  "If setting the read permission is supported" -> "If the platform supports settings a file's read permission".
> 
> 2. "If the platform or underlying  file system does not support" -> "If the platform does not support". The reason for this is that the underlying file systems may or may support file permissions, an implementation can't distinguish those.

Addressed in 5dabb216bcaf95bb3a3680fd76e5eb69f35f5fc1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15673#discussion_r1338858437

From alanb at openjdk.org  Wed Sep 27 16:28:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 16:28:27 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: 
References: 
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
 
 
Message-ID: <-rSkX6AyCfpiqcZp0Hadw0js8mWAScaUlsvgj4Ng1HE=.9090bf00-70bc-4bb9-8bbb-faa6a2ad8805@github.com>

On Wed, 27 Sep 2023 16:12:46 GMT, Jorn Vernee  wrote:

> Side note: I don't believe I have to add all the different error message translations right? Only the English version?

That's right, the translations will be updated towards the end of the release.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338874028

From jvernee at openjdk.org  Wed Sep 27 16:28:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 16:28:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v29]
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 two additional commits since the last revision:

 - Use IAE instead of UOE for unsupported char sets
 - Use abort instead of IEA when encountering wrong value for ENA attrib.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/f6ab4dc5..ea1b9c5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=27-28

  Stats: 18 lines in 7 files changed: 3 ins; 0 del; 15 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  Wed Sep 27 16:50:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 16:50:33 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v30]
In-Reply-To: 
References: 
Message-ID: <7SpZ55G-FXPaGDEborDn2ZhxF6EUPUdG6J1p56GLYo0=.603f7708-0bd0-4ab9-992a-6aabdc216cc0@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:

  drop unneeded @compile tags from jtreg tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/ea1b9c5f..2bc0a650

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=28-29

  Stats: 2 lines in 2 files changed: 0 ins; 1 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 jvernee at openjdk.org  Wed Sep 27 16:50:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 16:50:34 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: 
References: 
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
 <34zxg0Er5UaZKlmKxpvQ0QxAv8CeXEp0pSemqPgKquo=.165c5ccd-2873-42e7-aefa-e9ba2e78f661@github.com>
 
Message-ID: 

On Wed, 27 Sep 2023 14:52:52 GMT, Jorn Vernee  wrote:

>> test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckHoistingScaledIV.java line 32:
>> 
>>> 30:  * @modules jdk.incubator.vector
>>> 31:  * @compile -source ${jdk.version} TestRangeCheckHoistingScaledIV.java
>>> 32:  * @run main/othervm compiler.rangechecks.TestRangeCheckHoistingScaledIV
>> 
>> Not important but I assume the @compile line can be removed from a number of tests as it's no longer needed. It was needed for tests that didn't use @enablePreview.
>
> Ok, I'll go over all the tests that I've changed and see if there are `@compile` tags that can be removed

Besides the `compiler/rangechecks/TestRangeCheckHoistingScaledIV` test I found one other test that uses `@compile` in this manner: `java/lang/Thread/jni/AttachCurrentThread/AttachTest`. I've amended both.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338910373

From alanb at openjdk.org  Wed Sep 27 17:00:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 17:00:16 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v8]
In-Reply-To: 
References: 
 
Message-ID: <4RHReDiJzs7f6UvLOqwCRsDGYG-OPVHMKsJlIBjKUPI=.ae7a6a13-3f69-4a9f-a9bb-99b86babb8ff@github.com>

On Wed, 27 Sep 2023 16:19:04 GMT, Brian Burkhalter  wrote:

>> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316000: Address comment https://github.com/openjdk/jdk/pull/15673#discussion_r1338208315

Thanks for persistent with this, I think we have a winner. I'll add myself as Reviewer to the CSR when you create it.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15673#pullrequestreview-1647181749

From bpb at openjdk.org  Wed Sep 27 17:15:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 27 Sep 2023 17:15:16 GMT
Subject: RFR: 8316000: File.setExecutable silently fails if file does not
 exist [v8]
In-Reply-To: <4RHReDiJzs7f6UvLOqwCRsDGYG-OPVHMKsJlIBjKUPI=.ae7a6a13-3f69-4a9f-a9bb-99b86babb8ff@github.com>
References: 
 
 <4RHReDiJzs7f6UvLOqwCRsDGYG-OPVHMKsJlIBjKUPI=.ae7a6a13-3f69-4a9f-a9bb-99b86babb8ff@github.com>
Message-ID: 

On Wed, 27 Sep 2023 16:57:08 GMT, Alan Bateman  wrote:

> I'll add myself as Reviewer to the CSR when you create it.

CSR created. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15673#issuecomment-1737786818

From mcimadamore at openjdk.org  Wed Sep 27 17:29:29 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 27 Sep 2023 17:29:29 GMT
Subject: RFR: 8316970: Add internal annotation to mark restricted methods
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> This patch adds a new internal annotation that is used to mark all restricted me
> thods in the FFM API. The new annotation is similar to the one we used for preview API methods.
> 
> We plan to use the new annotation for adding new javac warnings when calling restricted methods, as well as to add better javadoc support for restricted methods.
> 
> I have added a test which, similar to the test for `@CallerSensitive` checks all methods in `java.base` that are annotated with `@Restricted` and makes sure they conform to the list of restricted methods.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Drop requires tag from test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15947/files
  - new: https://git.openjdk.org/jdk/pull/15947/files/f2f3692a..775d0887

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15947&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15947&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15947.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15947/head:pull/15947

PR: https://git.openjdk.org/jdk/pull/15947

From jvernee at openjdk.org  Wed Sep 27 17:29:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 17:29:30 GMT
Subject: RFR: 8316970: Add internal annotation to mark restricted methods
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 27 Sep 2023 17:23:48 GMT, Maurizio Cimadamore  wrote:

>> This patch adds a new internal annotation that is used to mark all restricted me
>> thods in the FFM API. The new annotation is similar to the one we used for preview API methods.
>> 
>> We plan to use the new annotation for adding new javac warnings when calling restricted methods, as well as to add better javadoc support for restricted methods.
>> 
>> I have added a test which, similar to the test for `@CallerSensitive` checks all methods in `java.base` that are annotated with `@Restricted` and makes sure they conform to the list of restricted methods.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop requires tag from test

Marked as reviewed by jvernee (Reviewer).

test/jdk/java/foreign/TestRestricted.java line 27:

> 25:  * @test
> 26:  * @enablePreview
> 27:  * @requires jdk.foreign.linker != "UNSUPPORTED"

FWIW, this `@requires` should not be needed since this test doesn't call `Linker.nativeLinker`

-------------

PR Review: https://git.openjdk.org/jdk/pull/15947#pullrequestreview-1647215073
PR Review Comment: https://git.openjdk.org/jdk/pull/15947#discussion_r1338954178

From rgiulietti at openjdk.org  Wed Sep 27 17:30:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 27 Sep 2023 17:30:17 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v11]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: <5Uwj-p3b99_joP1ik-XPn1WC5nIxmBp6ebcQPkfRXQw=.7a5d7a62-7f87-48f1-ac58-1a6b714db72c@github.com>

On Wed, 27 Sep 2023 09:35:47 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:
> 
>   code format

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)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1338962488

From iris at openjdk.org  Wed Sep 27 17:33:15 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 27 Sep 2023 17:33:15 GMT
Subject: RFR: 8316970: Add internal annotation to mark restricted methods
 [v2]
In-Reply-To: 
References: 
 
Message-ID: <6XNDNU2KCRkslhFUacdo7EAMzoLXrKvnHPGIMATGc6A=.d0add372-13fe-4b56-ba92-1099440f3668@github.com>

On Wed, 27 Sep 2023 17:29:29 GMT, Maurizio Cimadamore  wrote:

>> This patch adds a new internal annotation that is used to mark all restricted me
>> thods in the FFM API. The new annotation is similar to the one we used for preview API methods.
>> 
>> We plan to use the new annotation for adding new javac warnings when calling restricted methods, as well as to add better javadoc support for restricted methods.
>> 
>> I have added a test which, similar to the test for `@CallerSensitive` checks all methods in `java.base` that are annotated with `@Restricted` and makes sure they conform to the list of restricted methods.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop requires tag from test

I've confirmed that the identified set of restricted methods matches those declared for Java SE 21 (https://cr.openjdk.org/~iris/se/21/latestSpec/#Restricted-methods).

I'm looking forward to the planned javadoc support for restricted methods.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15947#pullrequestreview-1647234726

From duke at openjdk.org  Wed Sep 27 17:54:34 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Wed, 27 Sep 2023 17:54:34 GMT
Subject: RFR: 8317119: Unused imports in the java.util.stream package
Message-ID: 

Remove unused imports in the java.util.stream package.

-------------

Commit messages:
 - Remove unused imports.

Changes: https://git.openjdk.org/jdk/pull/15949/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15949&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317119
  Stats: 9 lines in 3 files changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15949.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15949/head:pull/15949

PR: https://git.openjdk.org/jdk/pull/15949

From rgiulietti at openjdk.org  Wed Sep 27 17:57:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 27 Sep 2023 17:57:15 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v6]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: 

On Wed, 27 Sep 2023 14:13:05 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

(not an official Reviewer)

-------------

Marked as reviewed by rgiulietti (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15906#pullrequestreview-1647271808

From alanb at openjdk.org  Wed Sep 27 18:34:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 18:34:14 GMT
Subject: RFR: 8316970: Add internal annotation to mark restricted methods
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 27 Sep 2023 17:29:29 GMT, Maurizio Cimadamore  wrote:

>> This patch adds a new internal annotation that is used to mark all restricted me
>> thods in the FFM API. The new annotation is similar to the one we used for preview API methods.
>> 
>> We plan to use the new annotation for adding new javac warnings when calling restricted methods, as well as to add better javadoc support for restricted methods.
>> 
>> I have added a test which, similar to the test for `@CallerSensitive` checks all methods in `java.base` that are annotated with `@Restricted` and makes sure they conform to the list of restricted methods.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop requires tag from test

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15947#pullrequestreview-1647328885

From naoto at openjdk.org  Wed Sep 27 19:06:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 27 Sep 2023 19:06:26 GMT
Subject: RFR: 8316974: ListFormat creation is unsuccessful for some of the
 supported Locales [v3]
In-Reply-To: 
References: 
Message-ID: 

> Some CLDR locales have partial list patterns, such as only the "end" pattern, and expect "start" and "middle" patterns to be inherited from parent locales. Made the code capable of the inheritance.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Inheritance validation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15935/files
  - new: https://git.openjdk.org/jdk/pull/15935/files/623d029f..7a52d1cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15935&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15935&range=01-02

  Stats: 14 lines in 3 files changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15935/head:pull/15935

PR: https://git.openjdk.org/jdk/pull/15935

From duke at openjdk.org  Wed Sep 27 19:13:02 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 27 Sep 2023 19:13:02 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v12]
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:

  fix : the exception thrown when the input does not include conversion is different from baselne.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/eafac656..8a6fe0e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=10-11

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 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 rriggs at openjdk.org  Wed Sep 27 19:43:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Sep 2023 19:43:12 GMT
Subject: RFR: 8316974: ListFormat creation is unsuccessful for some of the
 supported Locales [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 27 Sep 2023 19:06:26 GMT, Naoto Sato  wrote:

>> Some CLDR locales have partial list patterns, such as only the "end" pattern, and expect "start" and "middle" patterns to be inherited from parent locales. Made the code capable of the inheritance.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inheritance validation

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15935#pullrequestreview-1647430902

From joehw at openjdk.org  Wed Sep 27 19:49:11 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 27 Sep 2023 19:49:11 GMT
Subject: RFR: 8316974: ListFormat creation is unsuccessful for some of the
 supported Locales [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 27 Sep 2023 19:06:26 GMT, Naoto Sato  wrote:

>> Some CLDR locales have partial list patterns, such as only the "end" pattern, and expect "start" and "middle" patterns to be inherited from parent locales. Made the code capable of the inheritance.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inheritance validation

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15935#pullrequestreview-1647439043

From rgiulietti at openjdk.org  Wed Sep 27 19:54:16 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 27 Sep 2023 19:54:16 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v12]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: <97gdnLGZlApFDqc36dCRgUPhM_qECkN4qlu2h1ykEj4=.81e58386-b2dc-48d9-a5e3-cd3d2b32afa3@github.com>

On Wed, 27 Sep 2023 19:13:02 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:
> 
>   fix : the exception thrown when the input does not include conversion is different from baselne.

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;
        }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1737986458

From psandoz at openjdk.org  Wed Sep 27 20:12:10 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 27 Sep 2023 20:12:10 GMT
Subject: RFR: 8316998: Remove redundant type arguments
In-Reply-To: 
References: 
Message-ID: 

On Wed, 27 Sep 2023 00:58:01 GMT, Mourad Abbay  wrote:

> Remove cases of redundant type arguments in the java.util.stream package.

Looks like there are a few others in the package. In `Collectors`, see see construction of `CollectorImpl`. See also `DistinctOp`, `DoublePipeline`, `IntPipeline`, `LongPipeline`, `ReferencePipeline`, and `WhileOps`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15936#issuecomment-1738008502

From psandoz at openjdk.org  Wed Sep 27 20:18:12 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 27 Sep 2023 20:18:12 GMT
Subject: RFR: 8317034: Redundant type cast
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.

src/java.base/share/classes/java/util/stream/DoublePipeline.java line 391:

> 389:         if (maxSize < 0)
> 390:             throw new IllegalArgumentException(Long.toString(maxSize));
> 391:         return SliceOps.makeDouble(this, 0, maxSize);

Suggestion:

        return SliceOps.makeDouble(this, 0L, maxSize);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15942#discussion_r1339158996

From duke at openjdk.org  Wed Sep 27 21:26:46 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 27 Sep 2023 21:26:46 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v13]
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: <9PZeY6qD_y8-v4wSS5UgohDHFz8kaol2pMdg8gR9Nbo=.4145a0f3-fa09-456c-804c-5f82c8d1a50e@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)

??? has updated the pull request incrementally with one additional commit since the last revision:

  Refactor according to rgiulietti's suggestion and add testcases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/8a6fe0e9..3ff5121a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=11-12

  Stats: 47 lines in 2 files changed: 10 ins; 14 del; 23 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 naoto at openjdk.org  Wed Sep 27 21:29:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 27 Sep 2023 21:29:14 GMT
Subject: RFR: 8317119: Unused imports in the java.util.stream package
In-Reply-To: 
References: 
Message-ID: 

On Wed, 27 Sep 2023 17:45:58 GMT, Mourad Abbay  wrote:

> Remove unused imports in the java.util.stream package.

Please modify the copyright year accordingly. Otherwise LGTM

-------------

PR Review: https://git.openjdk.org/jdk/pull/15949#pullrequestreview-1647590729

From duke at openjdk.org  Wed Sep 27 21:30:58 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Wed, 27 Sep 2023 21:30:58 GMT
Subject: RFR: 8317034: Redundant type cast [v2]
In-Reply-To: 
References: 
Message-ID: 

> Remove redundant type cast in the java.util.stream package.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Apply Paul's review.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15942/files
  - new: https://git.openjdk.org/jdk/pull/15942/files/94813d5f..439a74ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15942&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15942&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15942/head:pull/15942

PR: https://git.openjdk.org/jdk/pull/15942

From dholmes at openjdk.org  Wed Sep 27 21:56:10 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 27 Sep 2023 21:56:10 GMT
Subject: RFR: 8316946: jtreg failure handler pages are mislabelling the
 jcmd/thread/dump_to_file results.
In-Reply-To: 
References: 
Message-ID: 

On Wed, 27 Sep 2023 07:11:59 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8316946?
> 
> Failure handler actions can specify a "successArtifacts" property value, which are file name(s) for which hypherlinks will be created in the "processes.html" file. This property value can contain replacable placeholder tokens like "%p" (process id) "%iterCount" (iteration count, if the action's command is repeated).
> 
> The issue here was caused by a bug in the handling of the "successArtifacts" value. If there were more than one process for which we were running the action (of collecting thread dumps), then the original (raw) value of "successArtifacts" property wasn't being held on to. As a result, for the second process for which the hyperlink was being created, an incorrect link would be generated.
> 
> The commit here retains the raw value of "successArtifacts" property in the `PatternAction` (just like we do for "args" property) so that it can be used to repeatedly replace the placeholders, each time the action is run for a different process.
> 
> I've run this change against our internal CI to verify it doesn't cause any regressions. tier1, tier2 and tier3 was run successfully. Additionally, I have run a couple of jtreg test cases which intentionally timeout, so that I can verify that the generated "processes.html" now contains the correct hyperlinks to the thread dump files for each process.

Based on the description this change looks good.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15939#pullrequestreview-1647620646

From duke at openjdk.org  Wed Sep 27 22:04:42 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Wed, 27 Sep 2023 22:04:42 GMT
Subject: RFR: 8316998: Remove redundant type arguments [v2]
In-Reply-To: 
References: 
Message-ID: 

> Remove cases of redundant type arguments in the java.util.stream package.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant type arguments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15936/files
  - new: https://git.openjdk.org/jdk/pull/15936/files/f984e52f..1107c222

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15936&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15936&range=00-01

  Stats: 170 lines in 7 files changed: 22 ins; 11 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/15936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15936/head:pull/15936

PR: https://git.openjdk.org/jdk/pull/15936

From duke at openjdk.org  Wed Sep 27 22:44:07 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Wed, 27 Sep 2023 22:44:07 GMT
Subject: RFR: 8316998: Remove redundant type arguments [v3]
In-Reply-To: 
References: 
Message-ID: 

> Remove cases of redundant type arguments in the java.util.stream package.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15936/files
  - new: https://git.openjdk.org/jdk/pull/15936/files/1107c222..d8b3d2ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15936&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15936&range=01-02

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15936/head:pull/15936

PR: https://git.openjdk.org/jdk/pull/15936

From duke at openjdk.org  Wed Sep 27 22:44:52 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Wed, 27 Sep 2023 22:44:52 GMT
Subject: RFR: 8317119: Unused imports in the java.util.stream package [v2]
In-Reply-To: 
References: 
Message-ID: 

> Remove unused imports in the java.util.stream package.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15949/files
  - new: https://git.openjdk.org/jdk/pull/15949/files/3ab7af5b..23b83138

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15949&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15949&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15949.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15949/head:pull/15949

PR: https://git.openjdk.org/jdk/pull/15949

From duke at openjdk.org  Wed Sep 27 22:47:43 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Wed, 27 Sep 2023 22:47:43 GMT
Subject: RFR: 8317034: Redundant type cast [v3]
In-Reply-To: 
References: 
Message-ID: 

> Remove redundant type cast in the java.util.stream package.

Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15942/files
  - new: https://git.openjdk.org/jdk/pull/15942/files/439a74ad..89daab63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15942&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15942&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15942/head:pull/15942

PR: https://git.openjdk.org/jdk/pull/15942

From naoto at openjdk.org  Wed Sep 27 23:12:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 27 Sep 2023 23:12:03 GMT
Subject: RFR: 8317119: Unused imports in the java.util.stream package [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 27 Sep 2023 22:44:52 GMT, Mourad Abbay  wrote:

>> Remove unused imports in the java.util.stream package.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15949#pullrequestreview-1647682749

From iris at openjdk.org  Wed Sep 27 23:16:29 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 27 Sep 2023 23:16:29 GMT
Subject: RFR: 8317119: Unused imports in the java.util.stream package [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 27 Sep 2023 22:44:52 GMT, Mourad Abbay  wrote:

>> Remove unused imports in the java.util.stream package.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15949#pullrequestreview-1647685756

From jlu at openjdk.org  Thu Sep 28 01:11:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Sep 2023 01:11:08 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest
Message-ID: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>

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)
- Removes both the test classes. 
- Replaces CollatorTest with CollatorUtils

-------------

Commit messages:
 - remove IntlTest and CollatorTest. introduce CollatorUtils
 - manual changes
 - scripted changes

Changes: https://git.openjdk.org/jdk/pull/15954/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316696
  Stats: 4295 lines in 79 files changed: 930 ins; 910 del; 2455 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 smarks at openjdk.org  Thu Sep 28 02:32:45 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 28 Sep 2023 02:32:45 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian  wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some more tabs

"Who reviewth the PR of Death
Must answer me these questions three
Ere the PR reopened be."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8311#issuecomment-1738350080

From duke at openjdk.org  Thu Sep 28 02:56:49 2023
From: duke at openjdk.org (duke)
Date: Thu, 28 Sep 2023 02:56:49 GMT
Subject: Withdrawn: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: 

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato  wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14404

From jpai at openjdk.org  Thu Sep 28 05:00:22 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 28 Sep 2023 05:00:22 GMT
Subject: RFR: 8316946: jtreg failure handler pages are mislabelling the
 jcmd/thread/dump_to_file results.
In-Reply-To: 
References: 
Message-ID: 

On Wed, 27 Sep 2023 07:11:59 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8316946?
> 
> Failure handler actions can specify a "successArtifacts" property value, which are file name(s) for which hypherlinks will be created in the "processes.html" file. This property value can contain replacable placeholder tokens like "%p" (process id) "%iterCount" (iteration count, if the action's command is repeated).
> 
> The issue here was caused by a bug in the handling of the "successArtifacts" value. If there were more than one process for which we were running the action (of collecting thread dumps), then the original (raw) value of "successArtifacts" property wasn't being held on to. As a result, for the second process for which the hyperlink was being created, an incorrect link would be generated.
> 
> The commit here retains the raw value of "successArtifacts" property in the `PatternAction` (just like we do for "args" property) so that it can be used to repeatedly replace the placeholders, each time the action is run for a different process.
> 
> I've run this change against our internal CI to verify it doesn't cause any regressions. tier1, tier2 and tier3 was run successfully. Additionally, I have run a couple of jtreg test cases which intentionally timeout, so that I can verify that the generated "processes.html" now contains the correct hyperlinks to the thread dump files for each process.

Thank you David for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15939#issuecomment-1738432110

From jpai at openjdk.org  Thu Sep 28 05:45:29 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 28 Sep 2023 05:45:29 GMT
Subject: Integrated: 8316946: jtreg failure handler pages are mislabelling the
 jcmd/thread/dump_to_file results.
In-Reply-To: 
References: 
Message-ID: 

On Wed, 27 Sep 2023 07:11:59 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8316946?
> 
> Failure handler actions can specify a "successArtifacts" property value, which are file name(s) for which hypherlinks will be created in the "processes.html" file. This property value can contain replacable placeholder tokens like "%p" (process id) "%iterCount" (iteration count, if the action's command is repeated).
> 
> The issue here was caused by a bug in the handling of the "successArtifacts" value. If there were more than one process for which we were running the action (of collecting thread dumps), then the original (raw) value of "successArtifacts" property wasn't being held on to. As a result, for the second process for which the hyperlink was being created, an incorrect link would be generated.
> 
> The commit here retains the raw value of "successArtifacts" property in the `PatternAction` (just like we do for "args" property) so that it can be used to repeatedly replace the placeholders, each time the action is run for a different process.
> 
> I've run this change against our internal CI to verify it doesn't cause any regressions. tier1, tier2 and tier3 was run successfully. Additionally, I have run a couple of jtreg test cases which intentionally timeout, so that I can verify that the generated "processes.html" now contains the correct hyperlinks to the thread dump files for each process.

This pull request has now been integrated.

Changeset: 42924ed4
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/42924ed4e59a9f93e165047bd91f829ba1e86c78
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8316946: jtreg failure handler pages are mislabelling the jcmd/thread/dump_to_file results.

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/15939

From alanb at openjdk.org  Thu Sep 28 07:17:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 28 Sep 2023 07:17:35 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v30]
In-Reply-To: <7SpZ55G-FXPaGDEborDn2ZhxF6EUPUdG6J1p56GLYo0=.603f7708-0bd0-4ab9-992a-6aabdc216cc0@github.com>
References: 
 <7SpZ55G-FXPaGDEborDn2ZhxF6EUPUdG6J1p56GLYo0=.603f7708-0bd0-4ab9-992a-6aabdc216cc0@github.com>
Message-ID: 

On Wed, 27 Sep 2023 16:50:33 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:
> 
>   drop unneeded @compile tags from jtreg tests

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1648059254

From abimpoudis at openjdk.org  Thu Sep 28 08:40:20 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 28 Sep 2023 08:40:20 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR finalizes the feature of unnamed variables and patterns.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change requires CSR request [JDK-8315851](https://bugs.openjdk.org/browse/JDK-8315851) to be approved
> 
> 
> 
> ### Reviewing
> 
Using git
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649` \
> `$ git checkout pull/15649`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/15649` \
> `$ git pull https://git.openjdk.org/jdk.git pull/15649/head`
> 
> 

> 
Using Skara CLI tools
> 
> Checkout this PR locally: \
> `$ git pr checkout 15649`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 15649`
> 
> 

> 
Using diff file
> 
> Download this PR as a diff file: \
> https://git.openjdk.org/jdk/pull/15649.diff
> 
> 

> 
> 
> ### Webrev
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/15649#issuecomment-1733906010)

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review by @mcimadamore

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/3becc945..630b128e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=01-02

  Stats: 128 lines in 11 files changed: 41 ins; 3 del; 84 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  Thu Sep 28 08:40:40 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 28 Sep 2023 08:40:40 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 26 Sep 2023 10:21:06 GMT, Maurizio Cimadamore  wrote:

>> test/langtools/tools/javac/lambda/IdentifierTest9.out line 33:
>> 
>>> 31: IdentifierTest.java:152:17: compiler.err.use.of.underscore.not.allowed
>>> 32: IdentifierTest.java:158:16: compiler.err.use.of.underscore.not.allowed.with.brackets
>>> 33: IdentifierTest.java:160:25: compiler.err.use.of.underscore.not.allowed
>> 
>> Note the errors are like:
>> 
>> /home/jlahoda/src/jdk/jdk2/test/langtools/tools/javac/lambda/IdentifierTest.java:160: error: as of release 21, the underscore keyword '_' is only allowed to declare
>>         for(String _s : _ ) {
>>                         ^
>>   unnamed patterns, local variables, exception parameters or lambda parameters
>> 
>> 
>> At least the release version should be updated, but to not let the message to be broken into two lines like this. Maybe produce a top-level diagnostic along the line of "underscore not allowed here" with sub-diagnostic with the details (which then can (maybe?) span multiple lines).
>> 
>> Also, the wording sounds to me like if there was a restriction in JDK 22, while underscore is actually permitted on more places than before.
>> 
>> So, maybe something like:
>> 
>> 
>> underscore not allowed here
>> as of release 9, ''_'' is a keyword, and may not be used as an identifier
>> as of release 21, ''_'' can be used as a name in the declaration of unnamed patterns, local variables, exception parameters or lambda parameters
>> 
>> ?
>> Just an idea.
>
> I agree. Also, this is not helped by the fact that in this particular message, the `_` does not appear in a variable declaration. Maybe we should use two distinct messages for when `_` is found as an "expression" (e.g. an identifier) and when it is used as a declaration _name_.

@mcimadamore @lahodaj I attempted to do this split for non variables that do not allow underscore. I print the simple version of the error message. Is that what you meant Maurizio?

I also fixed the `UnderscoreAsIdent` adding the missing `--release 9`. It was the same omission as with other tests that @lahodaj pointed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1339746518

From mcimadamore at openjdk.org  Thu Sep 28 09:49:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 09:49:25 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v3]
In-Reply-To: 
References: 
 
Message-ID: <1oDhU7VVjIshfuZZkqHH8O8w-R5J-nrKVQQrA7PiFCk=.a1f40dcb-b0dc-4814-a4fa-463334b520c8@github.com>

On Thu, 28 Sep 2023 08:40:20 GMT, Aggelos Biboudis  wrote:

>> This PR finalizes the feature of unnamed variables and patterns.
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> - [ ] Change requires CSR request [JDK-8315851](https://bugs.openjdk.org/browse/JDK-8315851) to be approved
>> 
>> 
>> 
>> ### Reviewing
>> 
Using git
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649` \
>> `$ git checkout pull/15649`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/15649` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/15649/head`
>> 
>> 

>> 
Using Skara CLI tools
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 15649`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 15649`
>> 
>> 

>> 
Using diff file
>> 
>> Download this PR as a diff file: \
>> https://git.openjdk.org/jdk/pull/15649.diff
>> 
>> 

>> 
>> 
>> ### Webrev
>> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/15649#issuecomment-1733906010)
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review by @mcimadamore

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15649#pullrequestreview-1648347760

From mcimadamore at openjdk.org  Thu Sep 28 09:49:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 09:49:28 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: <3uZtVJWgJ6rB14Obf-vPR78BGM3ksFUfV1h8srBNSZs=.69390415-3b3b-4032-8d21-907555cff993@github.com>

On Thu, 28 Sep 2023 08:38:27 GMT, Aggelos Biboudis  wrote:

>> I agree. Also, this is not helped by the fact that in this particular message, the `_` does not appear in a variable declaration. Maybe we should use two distinct messages for when `_` is found as an "expression" (e.g. an identifier) and when it is used as a declaration _name_.
>
> @mcimadamore @lahodaj I attempted to do this split for non variables that do not allow underscore. I print the simple version of the error message. Is that what you meant Maurizio?
> 
> I also fixed the `UnderscoreAsIdent` adding the missing `--release 9`. It was the same omission as with other tests that @lahodaj pointed.

This looks much better!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1339840526

From mcimadamore at openjdk.org  Thu Sep 28 09:53:35 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 09:53:35 GMT
Subject: Integrated: 8316970: Add internal annotation to mark restricted
 methods
In-Reply-To: 
References: 
Message-ID: 

On Wed, 27 Sep 2023 16:09:01 GMT, Maurizio Cimadamore  wrote:

> This patch adds a new internal annotation that is used to mark all restricted me
> thods in the FFM API. The new annotation is similar to the one we used for preview API methods.
> 
> We plan to use the new annotation for adding new javac warnings when calling restricted methods, as well as to add better javadoc support for restricted methods.
> 
> I have added a test which, similar to the test for `@CallerSensitive` checks all methods in `java.base` that are annotated with `@Restricted` and makes sure they conform to the list of restricted methods.

This pull request has now been integrated.

Changeset: 79812515
Author:    Maurizio Cimadamore 
URL:       https://git.openjdk.org/jdk/commit/798125152ba40ff2d093711629f275b5d74f0bcb
Stats:     221 lines in 7 files changed: 221 ins; 0 del; 0 mod

8316970: Add internal annotation to mark restricted methods

Reviewed-by: jvernee, iris, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15947

From rgiulietti at openjdk.org  Thu Sep 28 10:03:36 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 28 Sep 2023 10:03:36 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v13]
In-Reply-To: <9PZeY6qD_y8-v4wSS5UgohDHFz8kaol2pMdg8gR9Nbo=.4145a0f3-fa09-456c-804c-5f82c8d1a50e@github.com>
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 Wed, 27 Sep 2023 21:26:46 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:
> 
>   Refactor according to rgiulietti's suggestion and add testcases

For maintainability purposes, we should strive for simplicity and readability.

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 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 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).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1647449239
PR Review Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1339852931
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_r1339842414

From rgiulietti at openjdk.org  Thu Sep 28 10:03:39 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 28 Sep 2023 10:03:39 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v12]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Wed, 27 Sep 2023 19:13:02 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:
> 
>   fix : the exception thrown when the input does not include conversion is different from baselne.

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 Comment: https://git.openjdk.org/jdk/pull/15776#discussion_r1339135086

From jvernee at openjdk.org  Thu Sep 28 12:05:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 28 Sep 2023 12:05:35 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v31]
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 59 commits:

 - 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
 - fix typos
 - Tweak support for restricted methods
   
   Reviewed-by: jvernee, pminborg
 - Split note about byte order/alignment out of header
 - review comments
 - ... and 49 more: https://git.openjdk.org/jdk/compare/3481ecb2...72650c44

-------------

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=30
  Stats: 4352 lines in 258 files changed: 2211 ins; 1190 del; 951 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 mcimadamore at openjdk.org  Thu Sep 28 13:21:47 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 13:21:47 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls
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)

-------------

Commit messages:
 - Add tests
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/15964/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316971
  Stats: 95 lines in 14 files changed: 92 ins; 0 del; 3 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 mcimadamore at openjdk.org  Thu Sep 28 13:21:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 13:21:51 GMT
Subject: RFR: 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)

make/modules/java.base/Java.gmk line 26:

> 24: #
> 25: 
> 26: DISABLED_WARNINGS_java += this-escape restricted

I've disabled restricted warnings in java.base as there's a lot of restricted calls in the Linker API implementation :-)

make/test/BuildMicrobenchmark.gmk line 94:

> 92:     SMALL_JAVA := false, \
> 93:     CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
> 94:     DISABLED_WARNINGS := restricted this-escape processing rawtypes cast serial preview, \

This is needed so that we can compile FFM API benchmarks.

test/langtools/tools/javac/diags/examples.not-yet.txt line 219:

> 217: compiler.err.annotation.unrecognized.attribute.name
> 218: 
> 219: # this one is transitional (waiting for FFM API to exit preview)

Note: in principle I could have added an example for this diagnostic. In practice, the fact that FFM is still a preview API makes this a bit difficult - because we need the sample to also have enable preview flags, and also to catch a bunch of preview diagnostics (some of which I can't add directly as they are also excluded on this file). Since this PR already adds a test, I opted to exclude the diagnostic sample for now, and I will come back later (after FFM is no longer preview) to add one (so as to minimize disruption).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340137452
PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340137937
PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340142294

From jvernee at openjdk.org  Thu Sep 28 13:33:32 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 28 Sep 2023 13:33:32 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v32]
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:

  review @enablePreview from java/foreign/TestRestricted test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/72650c44..17dacbbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=30-31

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 mcimadamore at openjdk.org  Thu Sep 28 13:36:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 13:36:27 GMT
Subject: RFR: 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)

test/langtools/tools/javac/RestrictedMethods.java line 5:

> 3:  * @bug 8316971
> 4:  * @summary Smoke test for restricted method call warnings
> 5:  * @compile/fail/ref=RestrictedMethods.out -Xlint:restricted -Werror -XDrawDiagnostics --enable-preview --source ${jdk.version} RestrictedMethods.java

The `--enable-preview` related options will need to be removed when FFM is finalized

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340165979

From duke at openjdk.org  Thu Sep 28 14:00:30 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 28 Sep 2023 14:00:30 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v12]
In-Reply-To: <97gdnLGZlApFDqc36dCRgUPhM_qECkN4qlu2h1ykEj4=.81e58386-b2dc-48d9-a5e3-cd3d2b32afa3@github.com>
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
 <97gdnLGZlApFDqc36dCRgUPhM_qECkN4qlu2h1ykEj4=.81e58386-b2dc-48d9-a5e3-cd3d2b32afa3@github.com>
Message-ID: <8g_CiPIfpUm-VtAw_HqB9bfaUs1ZklEGRRxo61fZv_Q=.fff628f1-61ab-4f67-a381-c8a2699ca373@github.com>

On Wed, 27 Sep 2023 19:51:25 GMT, Raffaello Giulietti  wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix : the exception thrown when the input does not include conversion is different from baselne.
>
> 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1739269749

From rgiulietti at openjdk.org  Thu Sep 28 15:04:27 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 28 Sep 2023 15:04:27 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v13]
In-Reply-To: <9PZeY6qD_y8-v4wSS5UgohDHFz8kaol2pMdg8gR9Nbo=.4145a0f3-fa09-456c-804c-5f82c8d1a50e@github.com>
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 Wed, 27 Sep 2023 21:26:46 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:
> 
>   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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1739462969

From ihse at openjdk.org  Thu Sep 28 15:24:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 28 Sep 2023 15:24:25 GMT
Subject: RFR: 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)

Build changes look trivially fine.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15964#pullrequestreview-1649137432

From mcimadamore at openjdk.org  Thu Sep 28 15:36:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 15:36:30 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: 
References: 
Message-ID: <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>

> 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:

  Update warning message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15964/files
  - new: https://git.openjdk.org/jdk/pull/15964/files/8370e79d..21b7d860

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 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 vromero at openjdk.org  Thu Sep 28 15:59:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Sep 2023 15:59:27 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
References: 
 <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
Message-ID: 

On Thu, 28 Sep 2023 15:36:30 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)
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update warning message

question shouldn't the new Restricted annotation be annotated with the @PreviewFeature annotation? it depends on a preview feature

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 393:

> 391: 
> 392:     /**
> 393:      * Flag to indicate sealed class/interface declaration.

this javadoc needs to be adjusted to restricted methods

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15964#issuecomment-1739605513
PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340351919

From jjg at openjdk.org  Thu Sep 28 16:05:38 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 28 Sep 2023 16:05:38 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Tue, 26 Sep 2023 12:32:37 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:
> 
>   PreviewFeature annotated with JEP 457

I don't see anything specific to `javadoc`

-------------

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1649221047

From naoto at openjdk.org  Thu Sep 28 16:07:38 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 28 Sep 2023 16:07:38 GMT
Subject: Integrated: 8316974: ListFormat creation is unsuccessful for some of
 the supported Locales
In-Reply-To: 
References: 
Message-ID: 

On Tue, 26 Sep 2023 21:49:11 GMT, Naoto Sato  wrote:

> Some CLDR locales have partial list patterns, such as only the "end" pattern, and expect "start" and "middle" patterns to be inherited from parent locales. Made the code capable of the inheritance.

This pull request has now been integrated.

Changeset: 3481a485
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/3481a485716a1949706a4dcb94181b07e88e804d
Stats:     53 lines in 3 files changed: 47 ins; 0 del; 6 mod

8316974: ListFormat creation is unsuccessful for some of the supported Locales

Reviewed-by: joehw, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/15935

From egor.ziborov at gmail.com  Thu Sep 28 16:21:23 2023
From: egor.ziborov at gmail.com (=?utf-8?B?0JXQs9C+0YAg0JfQuNCx0L7RgNC+0LI=?=)
Date: Thu, 28 Sep 2023 19:21:23 +0300
Subject: ReservedStackAccess in ThreadLocal
Message-ID: <9815A00A-113E-43B8-84A8-EBAAF171227A@gmail.com>

Hello, everyone

I'm new there and writing this letter during advice of Dalibor Topic 

I faced an issue with SOE in ThreadLocal and want to add this java9 annotation on ThreadLocal#set. Does anyone have any concerns about it? 

Thank you in advance

From abimpoudis at openjdk.org  Thu Sep 28 16:46:11 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 28 Sep 2023 16:46:11 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v2]
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:

  Apply suggestions from code review
  
  Co-authored-by: Raffaello Giulietti 

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/d354f7eb..1ae06ac8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 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 Alan.Bateman at oracle.com  Thu Sep 28 16:55:47 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 28 Sep 2023 17:55:47 +0100
Subject: ReservedStackAccess in ThreadLocal
In-Reply-To: <9815A00A-113E-43B8-84A8-EBAAF171227A@gmail.com>
References: <9815A00A-113E-43B8-84A8-EBAAF171227A@gmail.com>
Message-ID: 

On 28/09/2023 17:21, ???? ??????? wrote:
> Hello, everyone
>
> I'm new there and writing this letter during advice of Dalibor Topic
>
> I faced an issue with SOE in ThreadLocal and want to add this java9 annotation on ThreadLocal#set. Does anyone have any concerns about it?
>
This annotation is for very core/critical areas that are particularly 
sensitive to SO. Did the SO that you observe just happen to be in 
ThreadLocal.set or is there more to this story? Asking because there are 
dozens places in java.base where the argument could be made but we have 
to be very careful to not sprinkle it about.

-Alab


From rgiulietti at openjdk.org  Thu Sep 28 17:22:25 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 28 Sep 2023 17:22:25 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 Thu, 28 Sep 2023 16:46:11 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:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Raffaello Giulietti 

There might be good reasons to have:

- `byte_char()` and `short_char()` in addition to `int_char()`
- `short_byte()` and `char_byte()` in addition to `int_byte()`
- `char_short()` in addition to `int_short()`

but I cannot see the rationale.

Maybe due to the language rules?
Or are they needed for the implementation of patterns, instanceof and switch?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1739727897

From jlu at openjdk.org  Thu Sep 28 17:26:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Sep 2023 17:26:36 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v2]
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)
> - Removes both the test classes. 
> - Replaces CollatorTest with CollatorUtils
> 
> Tiers 1-3 clean

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  CollatorUtils -> CollatorTestUtils

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15954/files
  - new: https://git.openjdk.org/jdk/pull/15954/files/8ee9f9c7..f90266f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=00-01

  Stats: 50 lines in 16 files changed: 3 ins; 0 del; 47 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 avoitylov at openjdk.org  Thu Sep 28 17:31:32 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Thu, 28 Sep 2023 17:31:32 GMT
Subject: RFR: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163 [v6]
In-Reply-To: 
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
 
Message-ID: 

On Wed, 27 Sep 2023 14:13:05 GMT, Aleksei Voitylov  wrote:

>> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
>> 
>> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Thanks everyone for prompt reviews! Could someone sponsor this? I also intend to backport to 21u soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15906#issuecomment-1739739777

From vromero at openjdk.org  Thu Sep 28 17:31:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Sep 2023 17:31:29 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
References: 
 <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
Message-ID: <4W6VSE5vQJGMJ-prAy0LIGNsLs7AjHvh5a8sfhJRyuA=.a858bf1e-561c-4d6b-a4c4-182a8e5c83fb@github.com>

On Thu, 28 Sep 2023 15:36:30 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)
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update warning message

test/langtools/tools/javac/RestrictedMethods.java line 34:

> 32:         }
> 33:     }
> 34: }

shouldn't this test include a case using method references? For example:

    void m(MemorySegment m) {
        foo(m::reinterpret);
    }

     void foo(LongFunction f) {}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340470730

From abimpoudis at openjdk.org  Thu Sep 28 17:50:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 28 Sep 2023 17:50:29 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 Thu, 28 Sep 2023 16:46:11 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:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Raffaello Giulietti 

At the moment the translation is uniform, (simply) computing the method name from the static types of the arguments and generating calls to those methods. This happens from two places, one from the `instanceof`:

> https://github.com/openjdk/jdk/pull/15638/files#diff-bc0df6dce7f74078bfca1e90bec75d7bb3d8b338933be725da78f0a8a7a0c78dR2999

and one from the `SwitchBootstraps` for `switch` (open the SwitchBootstraps file to see the diff, Github doesn't open it automatically):

> https://github.com/openjdk/jdk/pull/15638/files#diff-d71d82d68cc87a9c7179421f4a57eacdba822eb3e6a2b413ddb35f0b891a3764R246

I will try to find a good way to share code between the two places, by avoiding the further duplication of the code (@mcimadamore, @vicente-romero-oracle, @lahodaj any ideas?). 

In any case (with code duplication or not) maybe I can introduce a small table to "string intern" those names and avoid this computation altogether (including the map that you wrote above).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1739759884

From emcmanus at openjdk.org  Thu Sep 28 17:52:12 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Thu, 28 Sep 2023 17:52:12 GMT
Subject: RFR: 8317264: In `Pattern.Bound`, make some constants `static final`
Message-ID: 

It looks to have been an oversight that `final` was omitted. The fields are never assigned after initialization. `final` leads to shorter bytecode.

-------------

Commit messages:
 - In `Pattern.Bound`, make some constants `static final`.

Changes: https://git.openjdk.org/jdk/pull/15967/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15967&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317264
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15967/head:pull/15967

PR: https://git.openjdk.org/jdk/pull/15967

From naoto at openjdk.org  Thu Sep 28 17:59:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 28 Sep 2023 17:59:49 GMT
Subject: RFR: 8317126: Redundant entries in Windows `tzmappings` file
Message-ID: 

Removing redundant entries in `lib/tzmappings` file on Windows. The file maps Windows time zones to Java time zones according to the region. Since `001` means world, no region-specific entries are needed if those time zones are the same. The diff of the generated tzmappings files, before and after the fix, is attached.
[tzmappings.diff.txt](https://github.com/openjdk/jdk/files/12752377/tzmappings.diff.txt)

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/15968/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15968&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317126
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15968/head:pull/15968

PR: https://git.openjdk.org/jdk/pull/15968

From lancea at openjdk.org  Thu Sep 28 18:05:26 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 28 Sep 2023 18:05:26 GMT
Subject: RFR: 8317126: Redundant entries in Windows `tzmappings` file
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Sep 2023 17:37:00 GMT, Naoto Sato  wrote:

> Removing redundant entries in `lib/tzmappings` file on Windows. The file maps Windows time zones to Java time zones according to the region. Since `001` means world, no region-specific entries are needed if those time zones are the same. The diff of the generated tzmappings files, before and after the fix, is attached.
> [tzmappings.diff.txt](https://github.com/openjdk/jdk/files/12752377/tzmappings.diff.txt)

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15968#pullrequestreview-1649440371

From jlu at openjdk.org  Thu Sep 28 18:13:12 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Sep 2023 18:13:12 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v3]
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)
> - Removes both the test classes. 
> - Replaces CollatorTest with CollatorTestUtils
> 
> Tiers 1-3 clean

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  cleanup util classes in text/testlib

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15954/files
  - new: https://git.openjdk.org/jdk/pull/15954/files/f90266f4..3c676794

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=01-02

  Stats: 40 lines in 3 files changed: 20 ins; 2 del; 18 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 avoitylov at openjdk.org  Thu Sep 28 18:14:34 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Thu, 28 Sep 2023 18:14:34 GMT
Subject: Integrated: 8316879: RegionMatches1Tests fails if CompactStrings are
 disabled after JDK-8302163
In-Reply-To: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
References: <9MF6d4cM7AnkSZDlnGnNa2PFhK-GdhX5l5rspPQlBmI=.f01b9ed8-2728-4ca4-a1af-d64a2230119d@github.com>
Message-ID: 

On Mon, 25 Sep 2023 15:52:12 GMT, Aleksei Voitylov  wrote:

> test java.lang.String.RegionMatches1Tests fails on all platforms with -XX:-CompactStrings option and on ARM32 where Compact Strings is disabled by default. The fix is to return true immediately if len is negative, since for negative length this condition will never be satisfied.
> 
> Testing: JCK, JTREG passed with the fix with -XX:-CompactStrings on x86_64 and on ARM32.

This pull request has now been integrated.

Changeset: cfcbfc6c
Author:    Aleksei Voitylov 
Committer: Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/cfcbfc6cae7d8fc276c5a54917e97adea7cf5621
Stats:     29 lines in 2 files changed: 21 ins; 1 del; 7 mod

8316879: RegionMatches1Tests fails if CompactStrings are disabled after JDK-8302163

Reviewed-by: simonis, rgiulietti, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/15906

From jlu at openjdk.org  Thu Sep 28 18:16:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Sep 2023 18:16:01 GMT
Subject: RFR: JDK-8316559: Refactor some util/Calendar tests to JUnit [v6]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
> 
> Any files named BugXXXXXXX.java will be renamed after review.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Revert "rename files from bugXXXXXXX to something more descriptive"
  
  Renaming the files messes up the version history.
  
  This reverts commit a65b30987ba030c7698351b3afbc328b4eeb797b.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15853/files
  - new: https://git.openjdk.org/jdk/pull/15853/files/a65b3098..4e60ce55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15853&range=04-05

  Stats: 18 lines in 9 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/15853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15853/head:pull/15853

PR: https://git.openjdk.org/jdk/pull/15853

From iris at openjdk.org  Thu Sep 28 18:21:26 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 28 Sep 2023 18:21:26 GMT
Subject: RFR: 8317126: Redundant entries in Windows `tzmappings` file
In-Reply-To: 
References: 
Message-ID: <2yCzhFGeCqjEbyKDsu0W1tnwAKb1VoIADfLqqbFShgc=.f34875d6-83bb-4991-9f97-ad37f632ab93@github.com>

On Thu, 28 Sep 2023 17:37:00 GMT, Naoto Sato  wrote:

> Removing redundant entries in `lib/tzmappings` file on Windows. The file maps Windows time zones to Java time zones according to the region. Since `001` means world, no region-specific entries are needed if those time zones are the same. The diff of the generated tzmappings files, before and after the fix, is attached.
> [tzmappings.diff.txt](https://github.com/openjdk/jdk/files/12752377/tzmappings.diff.txt)

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15968#pullrequestreview-1649468588

From joehw at openjdk.org  Thu Sep 28 18:27:25 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 28 Sep 2023 18:27:25 GMT
Subject: RFR: 8317126: Redundant entries in Windows `tzmappings` file
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Sep 2023 17:37:00 GMT, Naoto Sato  wrote:

> Removing redundant entries in `lib/tzmappings` file on Windows. The file maps Windows time zones to Java time zones according to the region. Since `001` means world, no region-specific entries are needed if those time zones are the same. The diff of the generated tzmappings files, before and after the fix, is attached.
> [tzmappings.diff.txt](https://github.com/openjdk/jdk/files/12752377/tzmappings.diff.txt)

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15968#pullrequestreview-1649478174

From dl at openjdk.org  Thu Sep 28 19:46:17 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 28 Sep 2023 19:46:17 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v41]
In-Reply-To: 
References: 
Message-ID: <-uhAy4A_hB-guE8xTV7fH_ZOl_3B-VFiD2iVznRn4F0=.3afa92c6-9e63-4679-bdce-2c706136cb6e@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 88 additional commits since the last revision:

 - 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
 - Accommodate parallelism 0
 - Merge branch 'openjdk:master' into JDK-8288899
 - Fix header; don't shadow park state
 - Merge branch 'openjdk:master' into JDK-8288899
 - ... and 78 more: https://git.openjdk.org/jdk/compare/1e78ac82...8b888812

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/ed3b7493..8b888812

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=39-40

  Stats: 6225 lines in 223 files changed: 5095 ins; 552 del; 578 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  Thu Sep 28 19:49:02 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 28 Sep 2023 19:49:02 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v42]
In-Reply-To: 
References: 
Message-ID: <9zzBuj1h7axYfSILcDfP98dH8e_c17wJWl5HnIfAERE=.d6ab920b-d4f4-47a1-a62b-4655ef98c2a6@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:

  Streamline push; add redundant interrupts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/8b888812..85c26d2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=40-41

  Stats: 101 lines in 2 files changed: 19 ins; 37 del; 45 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 egor.ziborov at gmail.com  Thu Sep 28 20:33:40 2023
From: egor.ziborov at gmail.com (=?utf-8?B?0JXQs9C+0YAg0JfQuNCx0L7RgNC+0LI=?=)
Date: Thu, 28 Sep 2023 23:33:40 +0300
Subject: ReservedStackAccess in ThreadLocal
In-Reply-To: 
References: 
Message-ID: 

Hello, Alan

I?ve experienced SO in ThreadLocal#set on my production instance (more than that it?s happened in Spring?s ExposeInvocationInterceptor that uses TL as context storage)As a result of SO in ThreadLocal we?ve experienced unexpected errors with Spring AOP, but I?m sure that it could affects lots of frameworks

> 
> 28 ????. 2023 ?., ? 19:55, Alan Bateman  ???????(?):
> 
> ?On 28/09/2023 17:21, ???? ??????? wrote:
>> Hello, everyone
>> 
>> I'm new there and writing this letter during advice of Dalibor Topic
>> 
>> I faced an issue with SOE in ThreadLocal and want to add this java9 annotation on ThreadLocal#set. Does anyone have any concerns about it?
>> 
> This annotation is for very core/critical areas that are particularly sensitive to SO. Did the SO that you observe just happen to be in ThreadLocal.set or is there more to this story? Asking because there are dozens places in java.base where the argument could be made but we have to be very careful to not sprinkle it about.
> 
> -Alab
> 

From emcmanus at openjdk.org  Thu Sep 28 20:39:13 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Thu, 28 Sep 2023 20:39:13 GMT
Subject: RFR: 8317264: Pattern.Bound has `static` fields that should be
 `static final`. [v2]
In-Reply-To: 
References: 
Message-ID: 

> It looks to have been an oversight that `final` was omitted. The fields are never assigned after initialization. `final` leads to shorter bytecode.

Eamonn McManus has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into staticfinal
 - In `Pattern.Bound`, make some constants `static final`.
   
   It looks to have been an oversight that `final` was omitted. The fields are
   never assigned after initialization. `final` leads to shorter bytecode.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15967/files
  - new: https://git.openjdk.org/jdk/pull/15967/files/0a63d3f6..a10cf868

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15967&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15967&range=00-01

  Stats: 255 lines in 11 files changed: 209 ins; 2 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/15967.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15967/head:pull/15967

PR: https://git.openjdk.org/jdk/pull/15967

From jlu at openjdk.org  Thu Sep 28 20:39:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Sep 2023 20:39:29 GMT
Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for
 j.text.Format classes [v7]
In-Reply-To: 
References: 
Message-ID: 

> 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`).

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Implement CSR review and WS fix in CompactNumberFormat

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15459/files
  - new: https://git.openjdk.org/jdk/pull/15459/files/b4e7ddd1..d64e3f6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15459&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15459&range=05-06

  Stats: 57 lines in 9 files changed: 9 ins; 10 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/15459.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15459/head:pull/15459

PR: https://git.openjdk.org/jdk/pull/15459

From dnsimon at openjdk.org  Thu Sep 28 20:43:58 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 28 Sep 2023 20:43:58 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v23]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 17 May 2022 15:53:05 GMT, Jorn Vernee  wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github....
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
> 
>  - Merge branch 'master' into JEP-19-VM-IMPL2
>  - ifdef NOT_PRODUCT -> ifndef PRODUCT
>  - Missing ASSERT -> NOT_PRODUCT
>  - Cleanup UL usage
>  - Fix failure with SPEC disabled (accidentally dropped change)
>  - indentation
>  - fix space
>  - Merge branch 'master' into JEP-19-VM-IMPL2
>  - Undo spurious changes.
>  - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2
>  - ... and 95 more: https://git.openjdk.org/jdk/compare/af07919e...c3c1421b

src/hotspot/cpu/aarch64/universalNativeInvoker_aarch64.cpp line 105:

> 103: 
> 104:   RuntimeStub* stub =
> 105:     RuntimeStub::new_runtime_stub("nep_invoker_blob",

Is it acceptable for a VM fatal error to occur when the `RuntimeStub` cannot be allocated due to a (temporarily?) full code cache? If not, then you may want to do something like I'm doing in https://github.com/openjdk/jdk/pull/15970.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7959#discussion_r1340644955

From asemenyuk at openjdk.org  Thu Sep 28 21:04:41 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 28 Sep 2023 21:04:41 GMT
Subject: RFR: 8303959: tools/jpackage/share/RuntimePackageTest.java fails with
 java.lang.AssertionError missing files
Message-ID: 

Don't use JDK image from `$JAVA_HOME` as a value of `--runtime-image` jpackage cli option. Use jlink to create a runtime in test work dir if the default runtime is not specified and pass the location of jlink output.

-------------

Commit messages:
 - 8303959: tools/jpackage/share/RuntimePackageTest.java fails with java.lang.AssertionError missing files

Changes: https://git.openjdk.org/jdk/pull/15971/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15971&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303959
  Stats: 22 lines in 1 file changed: 18 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15971/head:pull/15971

PR: https://git.openjdk.org/jdk/pull/15971

From duke at openjdk.org  Thu Sep 28 21:12:37 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 28 Sep 2023 21:12:37 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v14]
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:

  Fix from @rgiulietti review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/3ff5121a..b19dc51f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=12-13

  Stats: 12 lines in 1 file changed: 1 ins; 4 del; 7 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 almatvee at openjdk.org  Thu Sep 28 21:17:22 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 28 Sep 2023 21:17:22 GMT
Subject: RFR: 8303959: tools/jpackage/share/RuntimePackageTest.java fails
 with java.lang.AssertionError missing files
In-Reply-To: 
References: 
Message-ID: <8a72CLog9i_zeLWbUizLq2q5IGpH74BNpFe31ZHVNh4=.af185fd2-d654-45c2-bc38-7f3a4be8a6a9@github.com>

On Thu, 28 Sep 2023 20:58:30 GMT, Alexey Semenyuk  wrote:

> Don't use JDK image from `$JAVA_HOME` as a value of `--runtime-image` jpackage cli option. Use jlink to create a runtime in test work dir if the default runtime is not specified and pass the location of jlink output.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15971#pullrequestreview-1649720770

From duke at openjdk.org  Thu Sep 28 21:18:28 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 28 Sep 2023 21:18:28 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v14]
In-Reply-To: 
References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.f4256331-2895-4694-9528-a44352119db9@github.com>
 
Message-ID: 

On Thu, 28 Sep 2023 21:12:37 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:
> 
>   Fix from @rgiulietti review

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-1740015776

From duke at openjdk.org  Thu Sep 28 21:40:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 28 Sep 2023 21:40:17 GMT
Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor
 specifiers [v15]
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:

  Improve the readability of parseArgument, suggestion from @rgiulietti

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15776/files
  - new: https://git.openjdk.org/jdk/pull/15776/files/b19dc51f..ad7f3bd1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15776&range=13-14

  Stats: 15 lines in 1 file changed: 3 ins; 5 del; 7 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 psandoz at openjdk.org  Thu Sep 28 21:55:24 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 28 Sep 2023 21:55:24 GMT
Subject: RFR: 8317264: Pattern.Bound has `static` fields that should be
 `static final`. [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 28 Sep 2023 20:39:13 GMT, Eamonn McManus  wrote:

>> It looks to have been an oversight that `final` was omitted. The fields are never assigned after initialization. `final` leads to shorter bytecode.
>
> Eamonn McManus has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into staticfinal
>  - In `Pattern.Bound`, make some constants `static final`.
>    
>    It looks to have been an oversight that `final` was omitted. The fields are
>    never assigned after initialization. `final` leads to shorter bytecode.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15967#pullrequestreview-1649761096

From duke at openjdk.org  Thu Sep 28 22:06:27 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 28 Sep 2023 22:06:27 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v21]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
 
Message-ID: 

On Sun, 24 Sep 2023 02:46:38 GMT, ???  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
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore StringUTF16.getChars(int,int,int,byte[]) and StringUTF16.getChars(long,int,int,byte[])

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-1740061373

From psandoz at openjdk.org  Thu Sep 28 22:08:26 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 28 Sep 2023 22:08:26 GMT
Subject: RFR: 8316998: Remove redundant type arguments in the
 java.util.stream package [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 27 Sep 2023 22:44:07 GMT, Mourad Abbay  wrote:

>> Remove cases of redundant type arguments in the java.util.stream package.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Looks good. Note a general rule to mostly follow is to try and stick to the prevailing style in source being modified and not make additional and unrelated changes (no matter how tempting it might be). In this case i don't have strong opinions on those changes and they did not detract from reviewing the code.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15936#pullrequestreview-1649772340

From psandoz at openjdk.org  Thu Sep 28 22:09:26 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 28 Sep 2023 22:09:26 GMT
Subject: RFR: 8317034: Remove redundant type cast in the java.util.stream
 package [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 27 Sep 2023 22:47:43 GMT, Mourad Abbay  wrote:

>> Remove redundant type cast in the java.util.stream package.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15942#pullrequestreview-1649773625

From psandoz at openjdk.org  Thu Sep 28 22:10:33 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 28 Sep 2023 22:10:33 GMT
Subject: RFR: 8317119: Remove unused imports in the java.util.stream
 package [v2]
In-Reply-To: 
References: 
 
Message-ID: <3w-2KhPk6AHD_k_OfCTackPJiM0EqkDAk_oqh_82wzM=.d30e824a-75a5-4b7c-805c-a58bfe9fce0f@github.com>

On Wed, 27 Sep 2023 22:44:52 GMT, Mourad Abbay  wrote:

>> Remove unused imports in the java.util.stream package.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15949#pullrequestreview-1649773090

From duke at openjdk.org  Thu Sep 28 22:10:34 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Thu, 28 Sep 2023 22:10:34 GMT
Subject: Integrated: 8317119: Remove unused imports in the java.util.stream
 package
In-Reply-To: 
References: 
Message-ID: 

On Wed, 27 Sep 2023 17:45:58 GMT, Mourad Abbay  wrote:

> Remove unused imports in the java.util.stream package.

This pull request has now been integrated.

Changeset: f2c221de
Author:    Mourad Abbay 
Committer: Paul Sandoz 
URL:       https://git.openjdk.org/jdk/commit/f2c221def1071e3200e502d0c40ace73a1d1967a
Stats:     11 lines in 3 files changed: 0 ins; 9 del; 2 mod

8317119: Remove unused imports in the java.util.stream package

Reviewed-by: naoto, iris, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/15949

From dl at openjdk.org  Thu Sep 28 22:50:10 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 28 Sep 2023 22:50:10 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v43]
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:

  Undo stray edit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/85c26d2c..9b714224

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=41-42

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 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 emcmanus at openjdk.org  Thu Sep 28 23:05:35 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Thu, 28 Sep 2023 23:05:35 GMT
Subject: Integrated: 8317264: Pattern.Bound has `static` fields that should be
 `static final`.
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Sep 2023 17:20:47 GMT, Eamonn McManus  wrote:

> It looks to have been an oversight that `final` was omitted. The fields are never assigned after initialization. `final` leads to shorter bytecode.

This pull request has now been integrated.

Changeset: ecb5e8a0
Author:    Eamonn McManus 
URL:       https://git.openjdk.org/jdk/commit/ecb5e8a03f67c92d7956201de1fa7d07cc6af9cb
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8317264: Pattern.Bound has `static` fields that should be `static final`.

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/15967

From asemenyuk at openjdk.org  Fri Sep 29 01:04:26 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 29 Sep 2023 01:04:26 GMT
Subject: RFR: 8317283: jpackage tests run osx-specific checks on windows and
 linux
Message-ID: <81hJlcvSkb29nl9wGl99s2_jyrxMk0rN3piPjji9bFg=.c37e5504-ff85-4afc-a975-a83aa7d2ebda@github.com>

- Don't run osx specific checks on Linux and Windows
 - Rework checks output from 

[17:31:52.845] TRACE: assertTrue(): Unexptected value in app image file for 
[17:31:52.860] TRACE: assertTrue(): Unexptected value in app image file for 

to

[22:07:46.519] TRACE: assertEquals(false): Check for unexptected value in app image file for 
[22:07:46.519] TRACE: assertEquals(false): Check for unexptected value in app image file for 

-------------

Commit messages:
 - 8317283: jpackage tests run osx-specific checks on windows and linux

Changes: https://git.openjdk.org/jdk/pull/15975/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15975&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317283
  Stats: 11 lines in 1 file changed: 4 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15975.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15975/head:pull/15975

PR: https://git.openjdk.org/jdk/pull/15975

From jlu at openjdk.org  Fri Sep 29 01:13:24 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Sep 2023 01:13:24 GMT
Subject: Integrated: JDK-8316559: Refactor some util/Calendar tests to JUnit
In-Reply-To: 
References: 
Message-ID: 

On Wed, 20 Sep 2023 23:20:43 GMT, Justin Lu  wrote:

> Please review this PR which converts some tests under _Calendar_ to use JUnit. These tests either previously used the internal _IntlTest_, or used no framework at all. 
> 
> Any files named BugXXXXXXX.java will be renamed after review.

This pull request has now been integrated.

Changeset: 355811a9
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/355811a996544c54cde9ff232450f5e5c8e1e632
Stats:     813 lines in 10 files changed: 339 ins; 259 del; 215 mod

8316559: Refactor some util/Calendar tests to JUnit

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/15853

From duke at openjdk.org  Fri Sep 29 01:18:03 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Fri, 29 Sep 2023 01:18:03 GMT
Subject: RFR: 8316998: Remove redundant type arguments in the
 java.util.stream package [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 28 Sep 2023 22:05:15 GMT, Paul Sandoz  wrote:

> Looks good. Note a general rule to mostly follow is to try and stick to the prevailing style in source being modified and not make additional and unrelated changes (no matter how tempting it might be). In this case i don't have strong opinions on those changes and they did not detract from reviewing the code.

Are you referring to the expand of lambdas and the extra whitespaces ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15936#issuecomment-1740152170

From almatvee at openjdk.org  Fri Sep 29 01:18:09 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 29 Sep 2023 01:18:09 GMT
Subject: RFR: 8317283: jpackage tests run osx-specific checks on windows
 and linux
In-Reply-To: <81hJlcvSkb29nl9wGl99s2_jyrxMk0rN3piPjji9bFg=.c37e5504-ff85-4afc-a975-a83aa7d2ebda@github.com>
References: <81hJlcvSkb29nl9wGl99s2_jyrxMk0rN3piPjji9bFg=.c37e5504-ff85-4afc-a975-a83aa7d2ebda@github.com>
Message-ID: 

On Thu, 28 Sep 2023 23:38:51 GMT, Alexey Semenyuk  wrote:

> - Don't run osx specific checks on Linux and Windows
>  - Rework checks output from 
> 
> [17:31:52.845] TRACE: assertTrue(): Unexptected value in app image file for 
> [17:31:52.860] TRACE: assertTrue(): Unexptected value in app image file for 
> 
> to
> 
> [22:07:46.519] TRACE: assertEquals(false): Check for unexptected value in app image file for 
> [22:07:46.519] TRACE: assertEquals(false): Check for unexptected value in app image file for 

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15975#pullrequestreview-1649891012

From psandoz at openjdk.org  Fri Sep 29 01:18:03 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 29 Sep 2023 01:18:03 GMT
Subject: RFR: 8316998: Remove redundant type arguments in the
 java.util.stream package [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: <3INqudxVX6F4bIXq7xg8iIXGc4-F9ejJLZtUGqQA_Xc=.14b23764-ffd2-4576-9450-0b37adb4ba8a@github.com>

On Fri, 29 Sep 2023 00:21:52 GMT, Mourad Abbay  wrote:

> Are you referring to the expand of lambdas and the extra whitespaces ?

Yes, sometimes the IDE just does it automatically!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15936#issuecomment-1740160022

From duke at openjdk.org  Fri Sep 29 01:18:03 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Fri, 29 Sep 2023 01:18:03 GMT
Subject: RFR: 8316998: Remove redundant type arguments in the
 java.util.stream package [v3]
In-Reply-To: <3INqudxVX6F4bIXq7xg8iIXGc4-F9ejJLZtUGqQA_Xc=.14b23764-ffd2-4576-9450-0b37adb4ba8a@github.com>
References: 
 
 
 
 <3INqudxVX6F4bIXq7xg8iIXGc4-F9ejJLZtUGqQA_Xc=.14b23764-ffd2-4576-9450-0b37adb4ba8a@github.com>
Message-ID: <8DI3R1egXGszYrGtOYZdtTMfroMNj0tKHRKdq1EbQQQ=.44e0438b-9945-44df-8d0a-24ebcaf695eb@github.com>

On Fri, 29 Sep 2023 00:35:08 GMT, Paul Sandoz  wrote:

> > Are you referring to the expand of lambdas and the extra whitespaces ?
> 
> Yes, sometimes the IDE just does it automatically!

Is there a way I can make the IDE respect the code style?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15936#issuecomment-1740161157

From psandoz at openjdk.org  Fri Sep 29 01:18:04 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 29 Sep 2023 01:18:04 GMT
Subject: RFR: 8316998: Remove redundant type arguments in the
 java.util.stream package [v3]
In-Reply-To: <8DI3R1egXGszYrGtOYZdtTMfroMNj0tKHRKdq1EbQQQ=.44e0438b-9945-44df-8d0a-24ebcaf695eb@github.com>
References: 
 
 
 
 <3INqudxVX6F4bIXq7xg8iIXGc4-F9ejJLZtUGqQA_Xc=.14b23764-ffd2-4576-9450-0b37adb4ba8a@github.com>
 <8DI3R1egXGszYrGtOYZdtTMfroMNj0tKHRKdq1EbQQQ=.44e0438b-9945-44df-8d0a-24ebcaf695eb@github.com>
Message-ID: 

On Fri, 29 Sep 2023 00:37:16 GMT, Mourad Abbay  wrote:

> > > Are you referring to the expand of lambdas and the extra whitespaces ?
> > 
> > 
> > Yes, sometimes the IDE just does it automatically!
> 
> Is there a way I can make the IDE respect the code style?

I doubt it, since 1) there is no agreed on code style in OpenJDK (although there have been attempts to propose one); and 2) each source file might have its own style (and there may even be inconsistencies within the same file).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15936#issuecomment-1740165050

From david.holmes at oracle.com  Fri Sep 29 02:37:38 2023
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Sep 2023 12:37:38 +1000
Subject: ReservedStackAccess in ThreadLocal
In-Reply-To: 
References: 
 
Message-ID: 

On 29/09/2023 6:33 am, ???? ??????? wrote:
> Hello, Alan
> 
> I?ve experienced SO in ThreadLocal#set on my production instance
> (more than that it?s happened in Spring?s ExposeInvocationInterceptor
> that uses TL as context storage)As a result of SO in ThreadLocal
> we?ve experienced unexpected errors with Spring AOP, but I?m sure
> that it could affects lots of frameworks
SOE will nearly always lead to unexpected errors, so that in itself is 
not sufficient justification for trying to apply ReservedStackAccess. We 
added RSA to address an insidious situation where SOE would leave 
ReentrantLocks in a broken state - and we wanted ReentrantLock to be as 
reliable as built-in monitor locks (or as near as feasible). So you need 
a very strong case to apply RSA elsewhere. You also need to be sure that 
the stack needed from the annotated method is small enough for the RSA 
mechanism to protect. Also note that RSA doesn't prevent SOE it simply 
defers it out of the critical code protected by SOE, so the problem is 
simply pushed to the caller.

Just my 2c.

David

>>
>> 28 ????. 2023 ?., ? 19:55, Alan Bateman  ???????(?):
>>
>> ?On 28/09/2023 17:21, ???? ??????? wrote:
>>> Hello, everyone
>>>
>>> I'm new there and writing this letter during advice of Dalibor Topic
>>>
>>> I faced an issue with SOE in ThreadLocal and want to add this java9 annotation on ThreadLocal#set. Does anyone have any concerns about it?
>>>
>> This annotation is for very core/critical areas that are particularly sensitive to SO. Did the SO that you observe just happen to be in ThreadLocal.set or is there more to this story? Asking because there are dozens places in java.base where the argument could be made but we have to be very careful to not sprinkle it about.
>>
>> -Alab
>>

From egor.ziborov at gmail.com  Fri Sep 29 04:26:42 2023
From: egor.ziborov at gmail.com (=?utf-8?B?0JXQs9C+0YAg0JfQuNCx0L7RgNC+0LI=?=)
Date: Fri, 29 Sep 2023 07:26:42 +0300
Subject: ReservedStackAccess in ThreadLocal
In-Reply-To: 
References: 
Message-ID: <6AB3CD11-00D3-49D9-9BCE-82F59CB5E234@gmail.com>

Unexpected behaviour is too common phrase - got it

As i sad i?ve experienced it in https://github.com/spring-projects/spring-framework/blob/main/spring-aop/src/main/java/org/springframework/aop/interceptor/ExposeInvocationInterceptor.java

Error on ThreadLocal#set in finally section there lead to leaving wrong state of TL (in my case it was non-null value into TL, that Spring?s AOP treats like ?part of recursion calls? and AOP will return null insteadof expected value (for all execution in such ?poisoned? thread)

I believe that the same situation is possible with ThreadLocal#remove too


> 29 ????. 2023 ?., ? 05:37, David Holmes  ???????(?):
> 
> ?On 29/09/2023 6:33 am, ???? ??????? wrote:
>> Hello, Alan
>> I?ve experienced SO in ThreadLocal#set on my production instance
>> (more than that it?s happened in Spring?s ExposeInvocationInterceptor
>> that uses TL as context storage)As a result of SO in ThreadLocal
>> we?ve experienced unexpected errors with Spring AOP, but I?m sure
>> that it could affects lots of frameworks
> SOE will nearly always lead to unexpected errors, so that in itself is not sufficient justification for trying to apply ReservedStackAccess. We added RSA to address an insidious situation where SOE would leave ReentrantLocks in a broken state - and we wanted ReentrantLock to be as reliable as built-in monitor locks (or as near as feasible). So you need a very strong case to apply RSA elsewhere. You also need to be sure that the stack needed from the annotated method is small enough for the RSA mechanism to protect. Also note that RSA doesn't prevent SOE it simply defers it out of the critical code protected by SOE, so the problem is simply pushed to the caller.
> 
> Just my 2c.
> 
> David
> 
>>> 
>>>> 28 ????. 2023 ?., ? 19:55, Alan Bateman  ???????(?):
>>> 
>>> ?On 28/09/2023 17:21, ???? ??????? wrote:
>>>> Hello, everyone
>>>> 
>>>> I'm new there and writing this letter during advice of Dalibor Topic
>>>> 
>>>> I faced an issue with SOE in ThreadLocal and want to add this java9 annotation on ThreadLocal#set. Does anyone have any concerns about it?
>>>> 
>>> This annotation is for very core/critical areas that are particularly sensitive to SO. Did the SO that you observe just happen to be in ThreadLocal.set or is there more to this story? Asking because there are dozens places in java.base where the argument could be made but we have to be very careful to not sprinkle it about.
>>> 
>>> -Alab
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jpai at openjdk.org  Fri Sep 29 05:48:15 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 29 Sep 2023 05:48:15 GMT
Subject: RFR: 8317141: Remove unused validIndex method from
 URLClassPath$JarLoader
Message-ID: 

Can I please get a review of this change which removes unused (internal) method from the `private` `URLClassPath$JarLoader`? 

The `validIndex` method which is being removed here was being used when JAR index was supported. We removed support for JAR index in https://bugs.openjdk.org/browse/JDK-8302819. This method is now a leftover and no longer used.

The commit in this PR also removes a couple of other member fields in `URLClassPath$JarLoader`. These fields too were used previously when JAR index was in use and are no longer used.

tier1, tier2 and tier3 tests continue to pass with this change.

-------------

Commit messages:
 - 8317141: Remove unused validIndex method from URLClassPath

Changes: https://git.openjdk.org/jdk/pull/15976/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15976&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317141
  Stats: 41 lines in 1 file changed: 0 ins; 38 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15976/head:pull/15976

PR: https://git.openjdk.org/jdk/pull/15976

From alanb at openjdk.org  Fri Sep 29 06:28:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 29 Sep 2023 06:28:04 GMT
Subject: RFR: 8317141: Remove unused validIndex method from
 URLClassPath$JarLoader
In-Reply-To: 
References: 
Message-ID: 

On Fri, 29 Sep 2023 05:41:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which removes unused (internal) method from the `private` `URLClassPath$JarLoader`? 
> 
> The `validIndex` method which is being removed here was being used when JAR index was supported. We removed support for JAR index in https://bugs.openjdk.org/browse/JDK-8302819. This method is now a leftover and no longer used.
> 
> The commit in this PR also removes a couple of other member fields in `URLClassPath$JarLoader`. These fields too were used previously when JAR index was in use and are no longer used.
> 
> tier1, tier2 and tier3 tests continue to pass with this change.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15976#pullrequestreview-1650122830

From mcimadamore at openjdk.org  Fri Sep 29 08:17:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Sep 2023 08:17:06 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: 
References: 
 <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
 
Message-ID: 

On Thu, 28 Sep 2023 15:56:36 GMT, Vicente Romero  wrote:

> question shouldn't the new Restricted annotation be annotated with the @PreviewFeature annotation? it depends on a preview feature

The Restricted annotation is an internal annotation only. So there is no value in annotating it with `@PreviewFeature`. Also, note that there is a PR already filed which, when integrated, will move the FFM API out of preview [1].

[1] - https://git.openjdk.org/jdk/pull/15103

> test/langtools/tools/javac/RestrictedMethods.java line 34:
> 
>> 32:         }
>> 33:     }
>> 34: }
> 
> shouldn't this test include a case using method references? For example:
> 
>     void m(MemorySegment m) {
>         foo(m::reinterpret);
>     }
> 
>      void foo(LongFunction f) {}
> 
> 
> we could also clarify in the CSR that the warning will also be issued for method references where the identifier after `::` is a restricted method

Good point. Will do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15964#issuecomment-1740490726
PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1341052841

From mcimadamore at openjdk.org  Fri Sep 29 08:30:07 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Sep 2023 08:30:07 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v3]
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:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15964/files
  - new: https://git.openjdk.org/jdk/pull/15964/files/21b7d860..1951b742

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=01-02

  Stats: 34 lines in 6 files changed: 23 ins; 0 del; 11 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 mcimadamore at openjdk.org  Fri Sep 29 08:30:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Sep 2023 08:30:09 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v3]
In-Reply-To: 
References: 
 
Message-ID: <-TtpM5jzRwQ8lw9joSyhFa1v3w5TWIbL3KyUkT-QSlo=.859e060a-5543-4b7b-add7-b1d525118e93@github.com>

On Fri, 29 Sep 2023 08:22:47 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)
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1921:

> 1919: 
> 1920: # 0: symbol, 1: symbol
> 1921: compiler.warn.restricted.method=\

I've updated the name of this key (from `compiler.warn.restricted.method.call` to make it more general, and also applicable in the case of method reference. Note that the warning text itself has not changed, as that was already correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1341062635

From lancea at openjdk.org  Fri Sep 29 10:26:00 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 29 Sep 2023 10:26:00 GMT
Subject: RFR: 8317141: Remove unused validIndex method from
 URLClassPath$JarLoader
In-Reply-To: 
References: 
Message-ID: 

On Fri, 29 Sep 2023 05:41:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which removes unused (internal) method from the `private` `URLClassPath$JarLoader`? 
> 
> The `validIndex` method which is being removed here was being used when JAR index was supported. We removed support for JAR index in https://bugs.openjdk.org/browse/JDK-8302819. This method is now a leftover and no longer used.
> 
> The commit in this PR also removes a couple of other member fields in `URLClassPath$JarLoader`. These fields too were used previously when JAR index was in use and are no longer used.
> 
> tier1, tier2 and tier3 tests continue to pass with this change.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15976#pullrequestreview-1650499922

From dfuchs at openjdk.org  Fri Sep 29 11:06:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 29 Sep 2023 11:06:18 GMT
Subject: RFR: 8317141: Remove unused validIndex method from
 URLClassPath$JarLoader
In-Reply-To: 
References: 
Message-ID: 

On Fri, 29 Sep 2023 05:41:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which removes unused (internal) method from the `private` `URLClassPath$JarLoader`? 
> 
> The `validIndex` method which is being removed here was being used when JAR index was supported. We removed support for JAR index in https://bugs.openjdk.org/browse/JDK-8302819. This method is now a leftover and no longer used.
> 
> The commit in this PR also removes a couple of other member fields in `URLClassPath$JarLoader`. These fields too were used previously when JAR index was in use and are no longer used.
> 
> tier1, tier2 and tier3 tests continue to pass with this change.

Looks reasonable to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15976#pullrequestreview-1650562494

From abimpoudis at openjdk.org  Fri Sep 29 14:57:51 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 29 Sep 2023 14:57:51 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 Thu, 28 Sep 2023 16:46:11 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:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Raffaello Giulietti 

So, the following shows the changes in `Lower.java`. It removes the methods you propose at the cost of a little bit more indirection which is ok. However, there is a non-trivial amount of re-engineering needed to be done on the `SwitchBootstrap` to support this change. It is not a mere porting of the logic from `Lower` to `SwitchBootstrap`. This is easy (despite the duplication of the code which I am inviting recommendations on how to avoid ? ). What is more, is that the `selectorType` changes within `createRepeatIndexSwitch` and needs to change in various sites as well e.g., `createMethodHandleSwitch`. @lahodaj am I correct?

(this is a footprint vs code uniformity question. If the bytecode instructions are exactly the same and in one occasion (`short_byte` -> `int_byte`) one bytecode instruction shorter, maybe code uniformity should win here?)


Subject: [PATCH] [WIP] Implement type pairs to exactnessMethod name
---
Index: src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java b/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java
--- a/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java	(revision 1ae06ac8f8cc0c0ce70920c2a62a7c13fdfc6f23)
+++ b/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java	(date 1695993935975)
@@ -36,46 +36,6 @@
 
     private ExactnessMethods() { }
 
-    /** Exactness method from byte to char
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean byte_char(byte n)    {return n == (char) n;}
-
-    /** Exactness method from short to byte
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean short_byte(short n)  {return n == (short)(byte)(n);}
-
-    /** Exactness method from short to char
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean short_char(short n)  {return n == (char)(n);}
-
-    /** Exactness method from char to byte
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean char_byte(char n)    {return n == (byte)(n);}
-
-    /** Exactness method from char to short
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean char_short(char n)   {return n == (short)(n);}
-
      /** Exactness method from int to byte
      *
      * @param n value
Index: src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java	(revision 1ae06ac8f8cc0c0ce70920c2a62a7c13fdfc6f23)
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java	(date 1695992937983)
@@ -103,6 +103,7 @@
     private final PkgInfo pkginfoOpt;
     private final boolean optimizeOuterThis;
     private final boolean useMatchException;
+    private final HashMap typePairToName;
 
     @SuppressWarnings("this-escape")
     protected Lower(Context context) {
@@ -134,6 +135,7 @@
         Preview preview = Preview.instance(context);
         useMatchException = Feature.PATTERN_SWITCH.allowedInSource(source) &&
                             (preview.isEnabled() || !preview.isPreview(Feature.PATTERN_SWITCH));
+        typePairToName = TypePairs.initialize(syms);
     }
 
     /** The currently enclosing class.
@@ -2996,15 +2998,81 @@
         }
     }
 
+    static class TypePairs {
+        public Type from, to;
+
+        public static TypePairs of(Symtab syms, Type from, Type to) {
+            if (from == syms.byteType || from == syms.shortType || from == syms.charType) {
+                from = syms.intType;
+            }
+            return new TypePairs(from, to);
+        }
+
+        private TypePairs(Type from, Type to) {
+            this.from = from;
+            this.to = to;
+        }
+
+        public static HashMap initialize(Symtab syms) {
+            HashMap typePairToName = new HashMap<>();
+            typePairToName.put(new TypePairs(syms.byteType,   syms.charType),   "int_char");      // redirected
+            typePairToName.put(new TypePairs(syms.shortType,  syms.byteType),   "int_byte");      // redirected
+            typePairToName.put(new TypePairs(syms.shortType,  syms.charType),   "int_char");      // redirected
+            typePairToName.put(new TypePairs(syms.charType,   syms.byteType),   "int_byte");      // redirected
+            typePairToName.put(new TypePairs(syms.charType,   syms.shortType),  "int_short");     // redirected
+            typePairToName.put(new TypePairs(syms.intType,    syms.byteType),   "int_byte");
+            typePairToName.put(new TypePairs(syms.intType,    syms.shortType),  "int_short");
+            typePairToName.put(new TypePairs(syms.intType,    syms.charType),   "int_char");
+            typePairToName.put(new TypePairs(syms.intType,    syms.floatType),  "int_float");
+            typePairToName.put(new TypePairs(syms.longType,   syms.byteType),   "long_byte");
+            typePairToName.put(new TypePairs(syms.longType,   syms.shortType),  "long_short");
+            typePairToName.put(new TypePairs(syms.longType,   syms.charType),   "long_char");
+            typePairToName.put(new TypePairs(syms.longType,   syms.intType),    "long_int");
+            typePairToName.put(new TypePairs(syms.longType,   syms.floatType),  "long_float");
+            typePairToName.put(new TypePairs(syms.longType,   syms.doubleType), "long_double");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.byteType),   "float_byte");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.shortType),  "float_short");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.charType),   "float_char");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.intType),    "float_int");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.longType),   "float_long");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.byteType),   "double_byte");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.shortType),  "double_short");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.charType),   "double_char");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.intType),    "double_int");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.longType),   "double_long");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.floatType),  "double_float");
+            return typePairToName;
+        }
+
+        @Override
+        public int hashCode() {
+            int code = 0;
+            code += from.tsym.hashCode();
+            code += to.tsym.hashCode();
+            return code;
+        }
+
+        @Override
+        public boolean equals(Object testName) {
+            if ((!(testName instanceof TypePairs testNameAsName))) return false;
+            else {
+                return this.from.tsym.equals(testNameAsName.from.tsym) &&
+                        this.to.tsym.equals(testNameAsName.to.tsym);
+            }
+        }
+    }
+
     private JCExpression getExactnessCheck(JCInstanceOf tree, JCExpression argument) {
-        Name exactnessFunction = names.fromString(types.unboxedTypeOrType(tree.expr.type).tsym.name.toString() + "_"+ tree.pattern.type.toString());
+        TypePairs pair = TypePairs.of(syms, types.unboxedTypeOrType(tree.expr.type), tree.pattern.type);
+
+        Name exactnessFunction = names.fromString(typePairToName.get(pair));
 
         // Resolve the exactness method
         Symbol ecsym = rs.resolveQualifiedMethod(null,
                 attrEnv,
                 syms.exactnessMethodsType,
                 exactnessFunction,
-                List.of(tree.expr.type),
+                List.of(pair.from),
                 List.nil());
 
         // Generate the method call ExactnessChecks.();

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1741006395

From asemenyuk at openjdk.org  Fri Sep 29 15:49:22 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 29 Sep 2023 15:49:22 GMT
Subject: Integrated: 8317283: jpackage tests run osx-specific checks on windows
 and linux
In-Reply-To: <81hJlcvSkb29nl9wGl99s2_jyrxMk0rN3piPjji9bFg=.c37e5504-ff85-4afc-a975-a83aa7d2ebda@github.com>
References: <81hJlcvSkb29nl9wGl99s2_jyrxMk0rN3piPjji9bFg=.c37e5504-ff85-4afc-a975-a83aa7d2ebda@github.com>
Message-ID: 

On Thu, 28 Sep 2023 23:38:51 GMT, Alexey Semenyuk  wrote:

> - Don't run osx specific checks on Linux and Windows
>  - Rework checks output from 
> 
> [17:31:52.845] TRACE: assertTrue(): Unexptected value in app image file for 
> [17:31:52.860] TRACE: assertTrue(): Unexptected value in app image file for 
> 
> to
> 
> [22:07:46.519] TRACE: assertEquals(false): Check for unexptected value in app image file for 
> [22:07:46.519] TRACE: assertEquals(false): Check for unexptected value in app image file for 

This pull request has now been integrated.

Changeset: 179792be
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/179792beb4e766756971fc3c80a79046b34893f4
Stats:     11 lines in 1 file changed: 4 ins; 0 del; 7 mod

8317283: jpackage tests run osx-specific checks on windows and linux

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/15975

From vromero at openjdk.org  Fri Sep 29 16:13:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Sep 2023 16:13:06 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v3]
In-Reply-To: 
References: 
 
Message-ID: <1F1qZ0zrP8REUWPhym75-TjmbDaz0gU-dubBBD8jQEA=.0101f7ee-9955-429a-97ab-34ead661ac6d@github.com>

On Fri, 29 Sep 2023 08:30:07 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)
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

looks good, thanks!

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15964#pullrequestreview-1651019837

From vromero at openjdk.org  Fri Sep 29 16:13:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Sep 2023 16:13:10 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: 
References: 
 <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
 
 
Message-ID: 

On Fri, 29 Sep 2023 08:14:29 GMT, Maurizio Cimadamore  wrote:

> > question shouldn't the new Restricted annotation be annotated with the @PreviewFeature annotation? it depends on a preview feature
> 
> The Restricted annotation is an internal annotation only. So there is no value in annotating it with `@PreviewFeature`. Also, note that there is a PR already filed which, when integrated, will move the FFM API out of preview [1].
> 
> [1] - https://git.openjdk.org/jdk/pull/15103

I see, thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15964#issuecomment-1741057810

From duke at openjdk.org  Fri Sep 29 16:22:14 2023
From: duke at openjdk.org (Mourad Abbay)
Date: Fri, 29 Sep 2023 16:22:14 GMT
Subject: Integrated: 8316998: Remove redundant type arguments in the
 java.util.stream package
In-Reply-To: 
References: 
Message-ID: 

On Wed, 27 Sep 2023 00:58:01 GMT, Mourad Abbay  wrote:

> Remove cases of redundant type arguments in the java.util.stream package.

This pull request has now been integrated.

Changeset: fa0697a6
Author:    Mourad Abbay 
Committer: Paul Sandoz 
URL:       https://git.openjdk.org/jdk/commit/fa0697a6371a89f19af3f88136886b0b2fbe4817
Stats:     182 lines in 8 files changed: 22 ins; 11 del; 149 mod

8316998: Remove redundant type arguments in the java.util.stream package

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/15936

From bpb at openjdk.org  Fri Sep 29 16:22:47 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 29 Sep 2023 16:22:47 GMT
Subject: Integrated: 8316000: File.setExecutable silently fails if file does
 not exist
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 22:22:47 GMT, Brian Burkhalter  wrote:

> On Windows, do not return `true` from the `java.io.File` methods `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the file does not exist.

This pull request has now been integrated.

Changeset: 49376e44
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/49376e445210d5ebe3a99a4e647deecec51f0784
Stats:     48 lines in 1 file changed: 24 ins; 12 del; 12 mod

8316000: File.setExecutable silently fails if file does not exist

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15673

From rgiulietti at openjdk.org  Fri Sep 29 16:38:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 29 Sep 2023 16:38:17 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 Thu, 28 Sep 2023 16:46:11 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:
> 
>   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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1741159978

From dfuchs at openjdk.org  Fri Sep 29 16:39:19 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 29 Sep 2023 16:39:19 GMT
Subject: RFR: 8316144: Remove unused field
 jdk.internal.util.xml.impl.XMLStreamWriterImpl.Element._Depth
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 27 Sep 2023 09:22:35 GMT, Andrey Turbanov  wrote:

> BTW, Who is Joe?

I believe that would be @JoeWang-Java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15692#issuecomment-1741186962

From naoto at openjdk.org  Fri Sep 29 16:41:31 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 29 Sep 2023 16:41:31 GMT
Subject: Integrated: 8317126: Redundant entries in Windows `tzmappings` file
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Sep 2023 17:37:00 GMT, Naoto Sato  wrote:

> Removing redundant entries in `lib/tzmappings` file on Windows. The file maps Windows time zones to Java time zones according to the region. Since `001` means world, no region-specific entries are needed if those time zones are the same. The diff of the generated tzmappings files, before and after the fix, is attached.
> [tzmappings.diff.txt](https://github.com/openjdk/jdk/files/12752377/tzmappings.diff.txt)

This pull request has now been integrated.

Changeset: 014c95a5
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/014c95a54d6cebe8f2b6422c2a484d538cdb2261
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8317126: Redundant entries in Windows `tzmappings` file

Reviewed-by: lancea, iris, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/15968

From sgehwolf at openjdk.org  Fri Sep 29 16:46:08 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 29 Sep 2023 16:46:08 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 19 Sep 2023 17:39:04 GMT, Alan Bateman  wrote:

> I did a pass over this to see where this proposal is currently at. At a high-level I think good progress since the discussion on leyden-dev some time ago. A few comments this from this pass:

Thanks, Alan!

> If I read it correctly, the default behavior is now to fail if jlink is executed from a run-time image that has been modified from the original and the packaged modules are not observable on the module path (this includes the default module path effectively appended by jlink). That seems the right policy as it avoids modifications by plugins or conf changes silently propagating.

Correct.

> If I read the code correctly, the error when a hash doesn't match is a very terse "Run image links only allow single-hop" so that probably needs to be looked to make sure the message says that the run-time image has been modified and maybe include one of the files/resources that has changed so there is something real to go with the error.

Not quite. See the example I've added in the [previous comment](https://github.com/openjdk/jdk/pull/14787#issuecomment-1673592876). It already includes that info. It looks like this:


Error: java.lang.IllegalArgumentException: /disk/openjdk/upstream-sources/git/jdk-jdk/build/jmodless-copy-jmods-removed/conf/net.properties has been modified. Please double check!


The message can of course be modified what we think is best.

> 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 (I suspect "single hop" won't be understood).

I believe keeping them both makes sense. Or at least make it so that it takes an argument to be able to distinguish between the two. The reason why I think this is useful is in the container case, where say - the JDK got installed by an installer - which didn't include packaged modules, but is otherwise a full JDK (with all modules). The installer already does integrity checking of the files and it might be desirable to do multi-hop evolutions, while still wanting to get warnings/errors on modified *configuration* files, for example. Happy to change the name of that flag/flags to `--clone-run-image=ignore-multi,warn-only` or something similar.

> Adding a new jdk.tools.jlink.internal.Archive implementation where the resources come from the run-time image seems a sensible approach. I don't particularly like the name "JmodLessArchive" because the original module may not have been packaged as a JMOD file, it may have been a modular JAR. Same comment on the BOM file "jmod_resources" added to the top-level directory of each module.

OK. How about `RunimageArchive` and  `runimage_resources` or `clone_resources`?

> I think it's clever to add this to each module in the container image but part of me wonders if it should be hidden in some way to avoid tools depending on it. I don't have a concrete suggestion except to wonder if jrtfs should filter it out, same thing in the SystemModuleReader code as ModuleReader.find("jmod_resources") will find the resource, could be an attractive nuisance.

That seems fine. I can add code to filter those resources out. On the other hand, no special handling is being made for `jdk/internal/vm/options`. Perhaps that should be handled uniformly?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1741195090

From bpb at openjdk.org  Fri Sep 29 16:52:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 29 Sep 2023 16:52:05 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v5]
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 three additional commits since the last revision:

 - 8287843: Strip prefix in more methods; remove bad test case
 - 8287843: Add WindowsPrefixes test
 - 8287843: Convert GetAbsolutePath and IsAbsolute tests to JUnit and add some test cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15603/files
  - new: https://git.openjdk.org/jdk/pull/15603/files/2ea422c1..63e2c5c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=03-04

  Stats: 219 lines in 5 files changed: 143 ins; 13 del; 63 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 asemenyuk at openjdk.org  Fri Sep 29 18:41:02 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 29 Sep 2023 18:41:02 GMT
Subject: Integrated: 8303959: tools/jpackage/share/RuntimePackageTest.java
 fails with java.lang.AssertionError missing files
In-Reply-To: 
References: 
Message-ID: 

On Thu, 28 Sep 2023 20:58:30 GMT, Alexey Semenyuk  wrote:

> Don't use JDK image from `$JAVA_HOME` as a value of `--runtime-image` jpackage cli option. Use jlink to create a runtime in test work dir if the default runtime is not specified and pass the location of jlink output.

This pull request has now been integrated.

Changeset: 5a6aa569
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/5a6aa569aa279141193038dc2e61e18a8b24bc11
Stats:     22 lines in 1 file changed: 18 ins; 1 del; 3 mod

8303959: tools/jpackage/share/RuntimePackageTest.java fails with java.lang.AssertionError missing files

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/15971

From darcy at openjdk.org  Fri Sep 29 18:42:50 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 29 Sep 2023 18:42:50 GMT
Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for
 j.text.Format classes [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 28 Sep 2023 20:39:29 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`).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement CSR review and WS fix in CompactNumberFormat

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15459#pullrequestreview-1651265283

From naoto at openjdk.org  Fri Sep 29 18:43:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 29 Sep 2023 18:43:10 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v3]
In-Reply-To: 
References: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
 
Message-ID: <6BbeeBkYfvFg6bZFFNew-M4O264VNDDBDMPUDEjh5cA=.400a68cb-cfe5-4b65-830a-56cd237a9300@github.com>

On Thu, 28 Sep 2023 18:13:12 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
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup util classes in text/testlib

Great to see this old proprietary test framework removed.

test/jdk/java/text/BreakIterator/BreakIteratorTest.java line 112:

> 110:         fail(message);
> 111:     }
> 112: 

We could simply eliminate these, by making `compareFragmentLists` return success indicator.

test/jdk/java/text/Format/ChoiceFormat/Bug4185732Test.java line 31:

> 29:  * @run junit Bug4185732Test
> 30:  * @summary test that ChoiceFormat invariants are preserved across serialization
> 31:  *          Run prepTest() if the invariant files are not yet generated.

I presume those invariant files are already in the test directory. I would simply remove this `prepTest()` altogether (also seen in other tests).

test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java line 62:

> 60:         new NumberRoundTrip().run(args);
> 61:     }
> 62: 

Probably we could eliminate `DEBUG`, and always print the information.

test/jdk/java/text/Format/common/FormatIteratorTest.java line 117:

> 115:             // The current tests are only appropriate for US. If tests are
> 116:             // added for other locales are added, then a property should be
> 117:             // added to each file (test) to be able to specify the locale.

Probably this comment needs to be preserved.

test/jdk/java/text/testlib/CollatorTestUtils.java line 32:

> 30:  * Collator related tests can use.
> 31:  */
> 32: public final class CollatorTestUtils {

Can the utilities in this class be merged into `TestUtils`?

test/jdk/java/util/TimeZone/TimeZoneBoundaryTest.java line 343:

> 341:       if (inDaylight != lastDST)
> 342:       {
> 343:       System.out.println("Switch " + (inDaylight ? "into" : "out of")

I'd remove this commented-out code entirely.

test/jdk/java/util/TimeZone/TimeZoneBoundaryTest.java line 398:

> 396:           {
> 397:           System.out.println("========================================");
> 398:           System.out.println("Stepping using millis");

This too

-------------

PR Review: https://git.openjdk.org/jdk/pull/15954#pullrequestreview-1651224754
PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341638631
PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341653934
PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341667327
PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341669151
PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341675031
PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341688583
PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341689009

From duke at openjdk.org  Fri Sep 29 18:54:22 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 29 Sep 2023 18:54:22 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 17:39:53 GMT, Raffaello Giulietti  wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   Uppercase JLA.

src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java line 508:

> 506:         try {
> 507:             return JLA.newStringNoRepl(bytes, StandardCharsets.ISO_8859_1);
> 508:         } catch (CharacterCodingException e) {

I want to know why newStringNoRepl throws CharacterCodingException instead of IllegalArgumentException. The place where I use it is forced to write redundant try_catch code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15861#discussion_r1341700677

From duke at openjdk.org  Fri Sep 29 19:00:00 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 29 Sep 2023 19:00:00 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 17:39:53 GMT, Raffaello Giulietti  wrote:

>> 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 incrementally with one additional commit since the last revision:
> 
>   Uppercase JLA.

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 110:

> 108:     private static final int NAN            = 5;
> 109: 
> 110:     private static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();

JLA is defined repeatedly in many places. Is this a good practice?  Can we use it directly, like this:

return SharedSecrets
           .getJavaLangAccess()
           .newStringNoRepl(bytes, StandardCharsets.ISO_8859_1);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15861#discussion_r1341704571

From rgiulietti at openjdk.org  Fri Sep 29 19:51:26 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 29 Sep 2023 19:51:26 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 29 Sep 2023 18:56:26 GMT, ???  wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Uppercase JLA.
>
> src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 110:
> 
>> 108:     private static final int NAN            = 5;
>> 109: 
>> 110:     private static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess();
> 
> JLA is defined repeatedly in many places. Is this a good practice?  Can we use it directly, like this:
> 
> return SharedSecrets
>            .getJavaLangAccess()
>            .newStringNoRepl(bytes, StandardCharsets.ISO_8859_1);

@wenshao I'll take a note for the next commit, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15861#discussion_r1341741225

From duke at openjdk.org  Fri Sep 29 20:03:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 29 Sep 2023 20:03:09 GMT
Subject: RFR: 8316426: Optimization for HexFormat.formatHex [v9]
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:

  Update full name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15768/files
  - new: https://git.openjdk.org/jdk/pull/15768/files/2ed9ac37..1463863e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15768&range=07-08

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 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 jlu at openjdk.org  Fri Sep 29 20:54:06 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Sep 2023 20:54:06 GMT
Subject: RFR: JDK-8315064: j.text.ChoiceFormat provides no specification on
 quoting behavior
Message-ID: 

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.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/15994/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15994&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315064
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15994.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15994/head:pull/15994

PR: https://git.openjdk.org/jdk/pull/15994

From jlu at openjdk.org  Fri Sep 29 21:22:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Sep 2023 21:22:01 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v4]
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 with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - merge master and resolve conflicts
 - implement feedback
 - cleanup util classes in text/testlib
 - CollatorUtils -> CollatorTestUtils
 - remove IntlTest and CollatorTest. introduce CollatorUtils
 - manual changes
 - scripted changes

-------------

Changes: https://git.openjdk.org/jdk/pull/15954/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=03
  Stats: 4461 lines in 79 files changed: 921 ins; 1075 del; 2465 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  Fri Sep 29 21:24:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Sep 2023 21:24:31 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v3]
In-Reply-To: <6BbeeBkYfvFg6bZFFNew-M4O264VNDDBDMPUDEjh5cA=.400a68cb-cfe5-4b65-830a-56cd237a9300@github.com>
References: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
 
 <6BbeeBkYfvFg6bZFFNew-M4O264VNDDBDMPUDEjh5cA=.400a68cb-cfe5-4b65-830a-56cd237a9300@github.com>
Message-ID: 

On Fri, 29 Sep 2023 17:30:42 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup util classes in text/testlib
>
> test/jdk/java/text/BreakIterator/BreakIteratorTest.java line 112:
> 
>> 110:         fail(message);
>> 111:     }
>> 112: 
> 
> We could simply eliminate these, by making `compareFragmentLists` return success indicator.

I think the previous code was set up so that if forward and backward did not pass, than expected and actual was skipped. Since IntlTest could be ran with -nothrow which allowed for tests to continue even if an error was encountered. 

Since that is no longer the case, I simply adjusted `compareFragmentLists` to fail if an error is found.

> test/jdk/java/text/testlib/CollatorTestUtils.java line 32:
> 
>> 30:  * Collator related tests can use.
>> 31:  */
>> 32: public final class CollatorTestUtils {
> 
> Can the utilities in this class be merged into `TestUtils`?

Merged CollatorTestUtils into TestUtils. I adjusted some method names which were previously in CollatorTestUtils to make more sense, now that they are in TestUtils.

> test/jdk/java/util/TimeZone/TimeZoneBoundaryTest.java line 343:
> 
>> 341:       if (inDaylight != lastDST)
>> 342:       {
>> 343:       System.out.println("Switch " + (inDaylight ? "into" : "out of")
> 
> I'd remove this commented-out code entirely.

Removed this and the other occurrence you spotted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341801084
PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341801193
PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341801258

From naoto at openjdk.org  Fri Sep 29 22:09:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 29 Sep 2023 22:09:54 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v4]
In-Reply-To: 
References: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
 
Message-ID: 

On Fri, 29 Sep 2023 21:22:01 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
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - merge master and resolve conflicts
>  - implement feedback
>  - cleanup util classes in text/testlib
>  - CollatorUtils -> CollatorTestUtils
>  - remove IntlTest and CollatorTest. introduce CollatorUtils
>  - manual changes
>  - scripted changes

test/jdk/java/util/Locale/LegacyCodesClassInvariant.java line 94:

> 92:                     fail("Locale didn't maintain invariants for: "+lang);
> 93:                     fail("         got: "+loc);
> 94:                     fail("    excpeted: "+expected);

This will only log the message in the first `fail()` invocation. This may be auto-converted by the script, so you might want to check other places.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341824281

From duke at openjdk.org  Fri Sep 29 23:07:22 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 29 Sep 2023 23:07:22 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v22]
In-Reply-To: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@github.com>
Message-ID: 

> 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

??? has updated the pull request incrementally with one additional commit since the last revision:

  Revert FormatItem related changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15699/files
  - new: https://git.openjdk.org/jdk/pull/15699/files/8ec66cca..d4f55ddc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15699&range=20-21

  Stats: 597 lines in 9 files changed: 239 ins; 260 del; 98 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 jlu at openjdk.org  Fri Sep 29 23:24:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Sep 2023 23:24:13 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v5]
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:

  get rid of subsequent fail()s

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15954/files
  - new: https://git.openjdk.org/jdk/pull/15954/files/95488eb2..47532e8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15954&range=03-04

  Stats: 38 lines in 5 files changed: 1 ins; 6 del; 31 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  Fri Sep 29 23:24:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 29 Sep 2023 23:24:14 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v4]
In-Reply-To: 
References: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
 
 
Message-ID: 

On Fri, 29 Sep 2023 22:00:23 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - merge master and resolve conflicts
>>  - implement feedback
>>  - cleanup util classes in text/testlib
>>  - CollatorUtils -> CollatorTestUtils
>>  - remove IntlTest and CollatorTest. introduce CollatorUtils
>>  - manual changes
>>  - scripted changes
>
> test/jdk/java/util/Locale/LegacyCodesClassInvariant.java line 94:
> 
>> 92:                     fail("Locale didn't maintain invariants for: "+lang);
>> 93:                     fail("         got: "+loc);
>> 94:                     fail("    excpeted: "+expected);
> 
> This will only log the message in the first `fail()` invocation. This may be auto-converted by the script, so you might want to check other places.

Good point, adjusted all locations of this to be contained in one `fail()` call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15954#discussion_r1341853125

From vromero at openjdk.org  Fri Sep 29 23:36:48 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Sep 2023 23:36:48 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com>

On Tue, 26 Sep 2023 12:32:37 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:
> 
>   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 is this change necessary?

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1341847954
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1341855569

From naoto at openjdk.org  Sat Sep 30 00:19:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 30 Sep 2023 00:19:48 GMT
Subject: RFR: JDK-8316696: Remove the testing base classes: IntlTest and
 CollatorTest [v5]
In-Reply-To: 
References: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
 
Message-ID: 

On Fri, 29 Sep 2023 23:24:13 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
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of subsequent fail()s

LGTM. Thanks for the changes

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15954#pullrequestreview-1651588585

From jpai at openjdk.org  Sat Sep 30 01:10:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 30 Sep 2023 01:10:08 GMT
Subject: RFR: 8317141: Remove unused validIndex method from
 URLClassPath$JarLoader
In-Reply-To: 
References: 
Message-ID: 

On Fri, 29 Sep 2023 05:41:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which removes unused (internal) method from the `private` `URLClassPath$JarLoader`? 
> 
> The `validIndex` method which is being removed here was being used when JAR index was supported. We removed support for JAR index in https://bugs.openjdk.org/browse/JDK-8302819. This method is now a leftover and no longer used.
> 
> The commit in this PR also removes a couple of other member fields in `URLClassPath$JarLoader`. These fields too were used previously when JAR index was in use and are no longer used.
> 
> tier1, tier2 and tier3 tests continue to pass with this change.

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15976#issuecomment-1741612815

From jpai at openjdk.org  Sat Sep 30 01:10:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 30 Sep 2023 01:10:08 GMT
Subject: Integrated: 8317141: Remove unused validIndex method from
 URLClassPath$JarLoader
In-Reply-To: 
References: 
Message-ID: <9-uWVmntaUJWoJ6ykkoFzVu6Aw_XSAEHqDdOs_GCMl8=.93a9faeb-ea06-48c2-970c-b97b647b31ed@github.com>

On Fri, 29 Sep 2023 05:41:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this change which removes unused (internal) method from the `private` `URLClassPath$JarLoader`? 
> 
> The `validIndex` method which is being removed here was being used when JAR index was supported. We removed support for JAR index in https://bugs.openjdk.org/browse/JDK-8302819. This method is now a leftover and no longer used.
> 
> The commit in this PR also removes a couple of other member fields in `URLClassPath$JarLoader`. These fields too were used previously when JAR index was in use and are no longer used.
> 
> tier1, tier2 and tier3 tests continue to pass with this change.

This pull request has now been integrated.

Changeset: 009f5e1f
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/009f5e1fa177eea326aefec0f995f589a01169d2
Stats:     41 lines in 1 file changed: 0 ins; 38 del; 3 mod

8317141: Remove unused validIndex method from URLClassPath$JarLoader

Reviewed-by: alanb, lancea, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/15976

From vromero at openjdk.org  Sat Sep 30 04:36:55 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 30 Sep 2023 04:36:55 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Tue, 26 Sep 2023 12:32:37 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:
> 
>   PreviewFeature annotated with JEP 457

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

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1341908521

From duke at openjdk.org  Sat Sep 30 07:26:51 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 30 Sep 2023 07:26:51 GMT
Subject: RFR: 8316150: Refactor get chars and string size [v4]
In-Reply-To: 
References: <2P7ehyIovPRDRMweJFQTlx0viQMq7oJCiTrUIANzAF0=.edc8ca97-50fc-4835-819a-42abb624ae83@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 shaojin.wensj at alibaba-inc.com  Sat Sep 30 12:06:33 2023
From: shaojin.wensj at alibaba-inc.com (=?UTF-8?B?5rip57uN6ZSmKOmrmOmTgSk=?=)
Date: Sat, 30 Sep 2023 20:06:33 +0800
Subject: =?UTF-8?B?QWRkaW5nIGFwcGVuZEhleCBtZXRob2QgdG8gU3RyaW5nQnVpbGRlcg==?=
Message-ID: 

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 alanb at openjdk.org  Sat Sep 30 14:42:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 30 Sep 2023 14:42:41 GMT
Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style
 paths DOS device paths [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 21 Sep 2023 00:46:45 GMT, Brian Burkhalter  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8287843: Move prefix stripping to separate method; add to isAbsolute
>
> Support for `isAbsolute` was added. All `jdk_core` tests still pass. Test cases still need to be added to `GetAbsolutePath.java` and `IsAbsolute.java`. These tests also appear ripe for conversion to JUnit 5.

@bplb and I discussed this issue yesterday and agreed that the right thing is to strip the prefix at the front door (meaning the normalization of the initial path string), all other directions appear to end up with inconsistencies and surprising behavior after several hops. Doing the right thing here means a behavior change for environments where the path string comes from native code using the long path or UNC prefix. This will need a CSR and release note. We agreed to reevaluate the compatibility impact before JDK 22 RDP1.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1741780454

From duke at openjdk.org  Sat Sep 30 15:52:55 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 30 Sep 2023 15:52:55 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v32]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 28 Sep 2023 13:33:32 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:
> 
>   review @enablePreview from java/foreign/TestRestricted test

Maybe?include ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1741795291

From jvernee at openjdk.org  Sat Sep 30 16:22:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 30 Sep 2023 16:22:56 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v32]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 28 Sep 2023 13:33:32 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:
> 
>   review @enablePreview from java/foreign/TestRestricted test

> Maybe include [openjdk/panama-foreign#864](https://github.com/openjdk/panama-foreign/pull/864)?

The leftover implementation-only changes will be ported over separately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1741806316

From ecki at zusammenkunft.net  Sat Sep 30 16:50:06 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Sat, 30 Sep 2023 18:50:06 +0200
Subject: Adding appendHex method to StringBuilder
In-Reply-To: 
References: 
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From shaojin.wensj at alibaba-inc.com  Sat Sep 30 19:28:15 2023
From: shaojin.wensj at alibaba-inc.com (=?UTF-8?B?5rip57uN6ZSmKOmrmOmTgSk=?=)
Date: Sun, 01 Oct 2023 03:28:15 +0800
Subject: =?UTF-8?B?5Zue5aSN77yaQWRkaW5nIGFwcGVuZEhleCBtZXRob2QgdG8gU3RyaW5nQnVpbGRlcg==?=
In-Reply-To: 
References: ,
 
Message-ID: <86df75e5-fe89-4690-98e0-0cfb95d79b19.shaojin.wensj@alibaba-inc.com>

Using the new method, the performance is improved by approximately 26% when running on MaxBookPro M1 Max.
```
Benchmark Mode Cnt Score Error Units
StringBuilders.appendHex8 avgt 15 15.259 ? 0.121 ns/op (+26.19%)
StringBuilders.appendHexCombine8 avgt 15 19.256 ? 0.059 ns/op
```
The test code is as follows:
```java
public class StringBuilders {
 @Benchmark
 public String appendHexCombine8() {
 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 appendHex8() {
 StringBuilder result = new StringBuilder();
 result.appendHex(2048);
 result.appendHex(31337);
 result.appendHex(0xbeefcace);
 result.appendHex(9000);
 result.appendHex(4711);
 result.appendHex(1337);
 result.appendHex(2100);
 result.appendHex(2600);
 return result.toString();
 }
}
```
------------------------------------------------------------------
????Bernd 
?????2023?10?1?(???) 00:50
???????(??) ; core-libs-dev 
????Re: Adding appendHex method to StringBuilder
Or maybe make it more generic and allow to specify the base as well, that?s more along the line of existing toString() methods of numbers.
besides convinience, I wonder if it would actually improve performance, how good is the JIT and EA in that case, did you run some benchmarks?
Gruss
Bernd
-- 
http://bernd.eckenfels.net 
Von: core-libs-dev  im Auftrag von ???(??) 
Gesendet: Samstag, September 30, 2023 2:07 PM
An: core-libs-dev 
Betreff: Adding appendHex method to StringBuilder
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 shaojin.wensj at alibaba-inc.com  Sat Sep 30 21:37:09 2023
From: shaojin.wensj at alibaba-inc.com (=?UTF-8?B?5rip57uN6ZSmKOmrmOmTgSk=?=)
Date: Sun, 01 Oct 2023 05:37:09 +0800
Subject: =?UTF-8?B?U3RyaW5nQnVpbGRlciBhZGQgYSBtZXRob2QgYXBwZW5kKGludCBpLCBpbnQgd2lkdGgsIGNo?=
 =?UTF-8?B?YXIgcGFkKQ==?=
Message-ID: <553d7a6f-5a6e-44c6-b599-78ce0ecdf55f.shaojin.wensj@alibaba-inc.com>

I suggest that StringBuilder and StringBuffer add a method append(int i, int width, char pad),
StringBuilder add method append(int i, int width, char pad). As follows:
```java
public abstract class AbstractBuilder {
 public AbstractStringBuilder append(int i, int width, char pad) {
 // ...
 }
}
```
Such functionality is needed in many places in the JDK. In the JDK date processing code, there are many places where StringBuilder.append(int) is used to specify the width. 
For example, in CalendarUtils, it is like this:
```java
package sun.util.calendar;
public final class CalendarUtils {
 /**
 * Mimics sprintf(buf, "%0*d", decaimal, width).
 */
 public static StringBuilder sprintf0d(StringBuilder sb, int value, int width) {
 long d = value;
 if (d < 0) {
 sb.append('-');
 d = -d;
 --width;
 }
 int n = 10;
 for (int i = 2; i < width; i++) {
 n *= 10;
 }
 for (int i = 1; i < width && d < n; i++) {
 sb.append('0');
 n /= 10;
 }
 sb.append(d);
 return sb;
 }
 public static StringBuffer sprintf0d(StringBuffer sb, int value, int width) {
 long d = value;
 if (d < 0) {
 sb.append('-');
 d = -d;
 --width;
 }
 int n = 10;
 for (int i = 2; i < width; i++) {
 n *= 10;
 }
 for (int i = 1; i < width && d < n; i++) {
 sb.append('0');
 n /= 10;
 }
 sb.append(d);
 return sb;
 }
}
```
This is the case in LocalTime. To fill in '0', first add 1000 or 1000_000 or 1000_000_000, and then do substring(1) processing after append. Such code has poor readability and poor performance.
```java
package java.time;
public final class LocalTime {
 public String toString() {
 StringBuilder buf = new StringBuilder(18);
 int hourValue = hour;
 int minuteValue = minute;
 int secondValue = second;
 int nanoValue = nano;
 buf.append(hourValue < 10 ? "0" : "").append(hourValue)
 .append(minuteValue < 10 ? ":0" : ":").append(minuteValue);
 if (secondValue > 0 || nanoValue > 0) {
 buf.append(secondValue < 10 ? ":0" : ":").append(secondValue);
 if (nanoValue > 0) {
 buf.append('.');
 if (nanoValue % 1000_000 == 0) {
 buf.append(Integer.toString((nanoValue / 1000_000) + 1000).substring(1));
 } else if (nanoValue % 1000 == 0) {
 buf.append(Integer.toString((nanoValue / 1000) + 1000_000).substring(1));
 } else {
 buf.append(Integer.toString((nanoValue) + 1000_000_000).substring(1));
 }
 }
 }
 return buf.toString();
 }
}
```
I submitted a PR ( https://github.com/openjdk/jdk/pull/15993  ), including the code and tests for the new method. Please review and don't hesitate to critique my approach and patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: